AR3200 Configuration Guide - VPN

Huawei AR3200 Series Enterprise Routers
V200R002C00
Configuration Guide - VPN

Issue
02
Date
2012-03-30
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2012. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

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

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 02 (2012-03-30)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.

About This Document
About This Document

Intended Audience
This document provides the basic concepts, configuration procedures, and configuration
examples in different application scenarios of the VPN supported by the AR3200 device.
This document describes how to configure the VPN.
This document is intended for:
l
Data configuration engineers
Commissioning engineers
Network monitoring engineers
System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
DANGER
WARNING
CAUTION
Issue 02 (2012-03-30)
Indicates a hazard with a high level of risk, which if not

avoided, will result in death or serious injury.
Indicates a hazard with a medium or low level of risk, which
if not avoided, could result in minor or moderate injury.
Indicates a potentially hazardous situation, which if not
avoided, could result in equipment damage, data loss,
performance degradation, or unexpected results.
TIP
Indicates a tip that may help you solve a problem or save

time.
NOTE
Provides additional information to emphasize or supplement

important points of the main text.

ii

About This Document
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.
Change History
Updates between document issues are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Changes in Issue 02 (2012-03-30)

Based on issue 01 (2011-12-30), the document is updated as follows:
The following information is modified:
l
6.4 Managing SSL VPN Users
6.6.1 Example for Configuring the SSL VPN Gateway
Changes in Issue 01 (2011-12-30)

Initial commercial release.
Issue 02 (2012-03-30)

iii

Contents
Contents
About This Document.....................................................................................................................ii
1 GRE Configuration.......................................................................................................................1
1.1 Introduction to GRE...........................................................................................................................................2
1.2 GRE Features Supported by the AR3200...........................................................................................................2
1.3 Configuring GRE................................................................................................................................................3
1.3.1 Establishing the Configuration Task.........................................................................................................3
1.3.2 Configuring a Tunnel Interface.................................................................................................................4
1.3.3 Configuring Routes for the Tunnel............................................................................................................5
1.3.4 (Optional) Configuring GRE Security Options.........................................................................................6
1.3.5 Checking the Configuration.......................................................................................................................7
1.4 Configuring a GRE Tunnel Between CE and PE...............................................................................................8
1.4.1 Establishing the Configuration Task.........................................................................................................8
1.4.2 Configuring the GRE Tunnel Interface on CE..........................................................................................9
1.4.3 Configuring the GRE Tunnel Interface on PE.........................................................................................10
1.4.4 Binding the GRE Tunnel with the VPN to Which CE belongs on PE....................................................12
1.4.5 Checking the Configuration.....................................................................................................................12
1.5 Configuring the Keepalive Function................................................................................................................13
1.5.1 Establishing the Configuration Task.......................................................................................................13
1.5.2 Enabling the Keepalive Function............................................................................................................14
1.6 Maintaining GRE..............................................................................................................................................16
1.6.1 Resetting the Statistics of a Tunnel Interface..........................................................................................16
1.6.2 Monitoring the Running Status of GRE..................................................................................................16
1.6.3 Debugging GRE......................................................................................................................................17
1.7 Configuration Examples...................................................................................................................................17
1.7.1 Example for Configuring a Static Route for GRE...................................................................................17
1.7.2 Example for Configuring a Dynamic Routing Protocol for GRE...........................................................21
1.7.3 Example for Configuring a GRE Tunnel to Transmit VPN Multicast Data Encrypted with IPSec........25
1.7.4 Example for Configuring the CE to Access a VPN Through a GRE Tunnel of the Public Network
..........................................................................................................................................................................31
1.7.5 Example for Configuring the Keepalive Function for GRE....................................................................38
2 BGP MPLS IP VPN Configuration..........................................................................................41

2.1 Introduction to BGP/MPLS IP VPN................................................................................................................43
Issue 02 (2012-03-30)

iv

Contents
2.2 BGP/MPLS IP VPN Features Supported by the AR3200................................................................................43

2.3 Configuring a VPN Instance Enabled with the IPv4 Address Family.............................................................44
2.3.2 Creating a VPN Instance.........................................................................................................................46
2.3.3 Configuring Attributes for the VPN Instance IPv4 Address Family.......................................................46
2.3.4 (Optional) Configuring MPLS Label Allocation Based on the VPN Instance IPv4 Address Family
..........................................................................................................................................................................48
2.4 Configuring Basic BGP/MPLS IP VPN...........................................................................................................50
2.4.2 Configuring a VPN Instance....................................................................................................................51
2.4.3 Binding an Interface with a VPN Instance..............................................................................................52
2.4.4 (Optional) Configuring a Router ID for a BGP VPN Instance IPv4 Address Family.............................52
2.4.5 Configuring MP-IBGP Between PEs......................................................................................................54
2.4.6 Configuring a Routing Protocol Between a PE and a CE.......................................................................54
2.5 Configuring Hub and Spoke.............................................................................................................................64
2.5.2 Creating a VPN Instance.........................................................................................................................65
2.5.3 Configuring Route Attributes of the VPN Instance.................................................................................67
2.5.4 Binding an Interface with the VPN Instance...........................................................................................69
2.5.5 Configuring MP-IBGP Between Hub-PE and Spoke-PE........................................................................69
2.5.6 Configuring Route Exchange Between PE and CE.................................................................................70
2.6 Configuring Inter-AS VPN Option A...............................................................................................................73
2.6.2 Establishing Inter-AS VPN Option A.....................................................................................................74
2.7 Configuring Inter-AS VPN Option B...............................................................................................................76
2.7.2 Configuring MP-IBGP Between PEs and ASBRs in the Same AS........................................................77
2.7.3 Configuring MP-EBGP Between ASBRs in Different ASs....................................................................78
2.7.4 Controlling the Receiving and Sending of VPN Routes by Using Routing Policies..............................79
2.7.5 (Optional) Storing Information About the VPN Instance on the ASBR.................................................81
2.7.6 (Optional) Enabling Next-Hop-based Label Allocation on the ASBR...................................................82
2.7.7 Configuring the Routing Protocol Between CE and PE..........................................................................83
2.8 Configuring Inter-AS VPN Option C (Solution 1)...........................................................................................85
2.8.2 Enabling the Labeled IPv4 Route Exchange...........................................................................................86
2.8.3 Configuring a Routing Policy to Control Label Distribution..................................................................88
2.8.4 Establishing the MP-EBGP Peer Relationship Between PEs..................................................................89
2.8.5 Configuring the Route Exchange Between CE and PE...........................................................................91
Issue 02 (2012-03-30)


Contents

2.9 Configuring Inter-AS VPN Option C (Solution 2)...........................................................................................92
2.9.2 Establishing the EBGP Peer Relationship Between ASBRs...................................................................93
2.9.3 Advertising the Routes of the PE in the Local AS to the Remote PE.....................................................94
2.9.4 Enabling the Capability of Exchanging Labeled IPv4 Routes................................................................95
2.9.5 Establishing an LDP LSP for the Labeled BGP Routes of the Public Network.....................................96
2.9.6 Establishing the MP-EBGP Peer Relationship Between PEs..................................................................97
2.9.7 Configuring the Route Exchange Between a CE and a PE.....................................................................98
2.10 Configuring HoVPN.....................................................................................................................................101
2.10.1 Establishing the Configuration Task...................................................................................................101
2.10.2 Specifying UPE...................................................................................................................................101
2.10.3 Advertising Default Routes of a VPN Instance...................................................................................102
2.10.4 Checking the Configuration.................................................................................................................102
2.11 Configuring a Multi-VPN-Instance CE........................................................................................................103
2.11.2 Configuring the OSPF Multi-Instance on the PE................................................................................104
2.11.3 Configuring the OSPF Multi-Instance on the Multi-Instance CE.......................................................105
2.11.4 Canceling the Loop Detection on the Multi-Instance CE....................................................................106
2.12 Connecting VPN and the Internet.................................................................................................................107
2.12.2 Configuring the Static Route on the CE..............................................................................................108
2.12.3 Configuring the Private Network Static Route on the PE...................................................................108
2.12.4 Configuring the Static Route to VPN on the Device of the Public Network......................................109
2.13 Configuring Route Reflection to Optimize the VPN Backbone Layer........................................................110
2.13.2 Configuring the Client PEs to Establish MP IBGP Connections with the RR....................................111
2.13.3 Configuring the RR to Establish MP IBGP Connections with the Client PEs....................................112
2.13.4 Configuring Route Reflection for BGP IPv4 VPN routes...................................................................114
2.14 Configuring Route Reflection to Optimize the VPN Access Layer.............................................................116
2.14.2 Configuring All Client CEs to Establish IBGP Connections with the RR..........................................117
2.14.3 Configuring the RR to Establish MP IBGP Connections with All Client CEs...................................117
2.14.4 Configuring Route Reflection for the Routes of the BGP VPN Instance...........................................119
2.15 Maintaining BGP/MPLS IP VPN.................................................................................................................122
2.15.1 Viewing the Integrated Route Statistics of All IPv4 VPN Instances..................................................122
2.15.2 Displaying BGP/MPLS IP VPN Information......................................................................................122
Issue 02 (2012-03-30)

vi

Contents
2.15.3 Checking the Network Connectivity and Reachability.......................................................................123

2.15.4 Resetting BGP Statistics of a VPN Instance IPv4 Address Family....................................................124
2.15.5 Resetting BGP Connections................................................................................................................124
2.16 Configuration Examples...............................................................................................................................125
2.16.1 Example for Configuring BGP/MPLS IP VPN...................................................................................125
2.16.2 Example for Configuring the BGP AS Number Substitution..............................................................136
2.16.3 Example for Configuring Hub and Spoke...........................................................................................141
2.16.4 Example for Configuring Inter-AS VPN Option A.............................................................................150
2.16.5 Example for Configuring Inter-AS VPN Option B.............................................................................159
2.16.6 Example for Configuring Inter-AS VPN Option C.............................................................................165
2.16.7 Example for Configuring Inter-AS VPN Option C (Solution 2).........................................................172
2.16.8 Example for Configuring HoVPN.......................................................................................................184
2.16.9 Example for Configuring Multi-VPN-Instance CE.............................................................................191
2.16.10 Example for Connecting VPN and Internet.......................................................................................201
3 L2TP Configuration...................................................................................................................208
3.1 L2TP Overview..............................................................................................................................................209
3.1.1 Introduction to L2TP.............................................................................................................................209
3.1.2 L2TP Features Supported by the AR3200.............................................................................................209
3.2 Configuring Basic L2TP Functions................................................................................................................210
3.2.1 Establishing the Configuration Task.....................................................................................................210
3.2.2 Configuring Basic L2TP Capability......................................................................................................211
3.3 Configuring LAC............................................................................................................................................212
3.3.2 Configuring an L2TP Connection on LAC Side...................................................................................213
3.3.3 (Optional) Configuring LAC Auto-Dial................................................................................................213
3.3.4 (Optional) Configuring Local Authentication on LAC Side.................................................................215
3.3.5 (Optional) Configuring RADIUS Authentication on LAC Side...........................................................215
3.3.6 Checking the Configuration...................................................................................................................217
3.4 Configuring LNS............................................................................................................................................218
3.4.2 Configuring an L2TP Connection on LNS............................................................................................220
3.4.3 (Optional) Configuring User Authentication on LNS...........................................................................221
3.4.4 Allocating Addresses to Access Users..................................................................................................222
3.5 Adjusting L2TP Connection...........................................................................................................................223
3.5.2 Configuring Security Options for L2TP Connection............................................................................224
3.5.3 Configuring L2TP Connection Parameters...........................................................................................225
3.6 Maintaining L2TP...........................................................................................................................................226
3.6.1 Disconnecting a Tunnel Forcibly..........................................................................................................226
3.6.2 Monitoring the Running Status of L2TP...............................................................................................226
3.6.3 Debugging L2TP Information...............................................................................................................227
Issue 02 (2012-03-30)

vii

Contents
3.7 Configuration Examples.................................................................................................................................227

3.7.1 Example for Configuring NAS-Initialized VPNs (Domain Name Access)..........................................227
3.7.2 Example for Configuring NAS-Initialized VPNs (Dialup Access).......................................................232
3.7.3 Example for Configuring Client-Initialized VPNs................................................................................235
3.7.4 Example for Configuring LAC-Auto-Initiated VPN.............................................................................238
4 IPSec Configuration..................................................................................................................242
4.1 IPSec Overview..............................................................................................................................................244
4.2 IPSec Features Supported by the AR3200.....................................................................................................245
4.3 Establishing an IPSec Tunnel Manually.........................................................................................................246
4.3.2 Defining Protected Data Flows..............................................................................................................247
4.3.3 Configuring an IPSec Proposal..............................................................................................................248
4.3.4 Configuring an IPSec Policy.................................................................................................................248
4.3.5 Applying an IPSec Policy to an Interface..............................................................................................250
4.4 Establishing an IPSec Tunnel Through IKE Negotiation...............................................................................251
4.4.2 Defining Protected Data Flows..............................................................................................................252
4.4.3 (Optional) Configuring an IKE Proposal...............................................................................................253
4.4.4 Configuring an IKE Peer.......................................................................................................................254
4.4.5 Configuring an IPSec Proposal..............................................................................................................256
4.4.6 Configuring an IPSec Policy.................................................................................................................257
4.4.7 Configuring an IPSec Policy Template.................................................................................................258
4.4.8 (Optional) Setting Optional Parameters................................................................................................259
4.4.9 (Optional) Configuring Route Injection................................................................................................261
4.4.10 Applying an IPSec policy to an interface............................................................................................261
4.5 Establishing an IPSec Tunnel Using an IPSec Tunnel Interface....................................................................262
4.5.2 Configuring an IPSec Profile.................................................................................................................263
4.5.3 Configuring an IPSec Tunnel Interface.................................................................................................264
4.6 Establishing an IPSec Tunnel Using the Efficient VPN Policy.....................................................................266
4.6.2 Configuring Client Mode.......................................................................................................................267
4.6.3 Configuring Network Mode..................................................................................................................270
4.6.4 Verifying the Configuration..................................................................................................................273
4.7 Maintaining IPSec..........................................................................................................................................273
4.7.1 Displaying the IPSec Configuration......................................................................................................273
4.7.2 Clearing IPSec Information...................................................................................................................274
4.8.1 Example for Establishing an SA Manually...........................................................................................275
Issue 02 (2012-03-30)

viii

Contents
4.8.2 Example for Configuring IKE Negotiation Using Default Settings......................................................279

4.8.3 Example for Configuring IKE Negotiation...........................................................................................284
4.8.4 Example for Establishing an IPSec Tunnel Using an IPSec Tunnel Interface......................................291
4.8.5 Example for Establishing an SA Using Efficient VPN in Client Mode................................................295
4.8.6 Example for Establishing an SA Using Efficient VPN in Network Mode............................................300
5 DSVPN Configuration............................................................................................................. 304

5.1 DSVPN Overview..........................................................................................................................................305
5.2 DSVPN Features Supported by the AR3200..................................................................................................305
5.3 Configuring DSVPN.......................................................................................................................................306
5.3.2 Configuring MGRE...............................................................................................................................307
5.3.3 Configuring Tunnel Routes...................................................................................................................307
5.3.4 Configuring NHRP on a Branch............................................................................................................308
5.3.5 Configuring NHRP on the Central Office.............................................................................................309
5.3.6 (Optional) Configuring an IPSec Profile...............................................................................................310
5.4 Maintaining DSVPN.......................................................................................................................................312
5.4.1 Displaying the DSVPN Configuration..................................................................................................312
5.4.2 Clearing DSVPN Statistics....................................................................................................................312
5.5.1 Example for Configuring DSVPN When Branches Learn Routes from Each Other............................313
5.5.2 Example for Configuring DSVPN When Branches Have Only Summarized Routes to the Central Office
........................................................................................................................................................................318
6 SSL VPN Configuration...........................................................................................................323

6.1 SSL VPN Overview........................................................................................................................................324
6.2 SSL VPN Features Supported by the AR3200...............................................................................................325
6.3 Configuring Basic SSL VPN Functions.........................................................................................................326
6.3.2 Creating a Virtual Gateway...................................................................................................................327
6.3.3 Configuring Intranet and Extranet Interfaces........................................................................................327
6.3.4 Binding an AAA Domain to the Virtual Gateway................................................................................328
6.3.5 Enabling Basic SSL VPN Functions.....................................................................................................329
6.4 Managing SSL VPN Users.............................................................................................................................330
6.5 Configuring SSL VPN Services.....................................................................................................................332
6.5.2 Creating a Virtual Gateway...................................................................................................................333
6.5.3 Configuring the Web Proxy Service......................................................................................................333
6.5.4 Configuring the Port Forwarding Service.............................................................................................334
6.5.5 Configuring the IP Forwarding Service.................................................................................................335
Issue 02 (2012-03-30)

ix

Contents
6.6.1 Example for Configuring the SSL VPN Gateway.................................................................................337
Issue 02 (2012-03-30)


1 GRE Configuration
GRE Configuration
About This Chapter

Generic Routing Encapsulation (GRE) encapsulates the packets of certain network layer
protocols so that the encapsulated packets can be transmitted over the IPv4 network.
1.1 Introduction to GRE
The transmission of packets in a Generic Routing Encapsulation (GRE) tunnel involves two
processes: encapsulation and decapsulation. After receiving a packet of a certain network layer
protocol that needs to be encapsulated and routed, the system adds a GRE header to the packet,
and encapsulates the packet into a packet of another protocol, such as IP.
1.2 GRE Features Supported by the AR3200
GRE features supported by the AR3200 include the following: enlargement of the operation
scope of the network running a hop-limited protocol, and working in conjunction with the IP
Security Protocol (IPSec) to compensate for the IPSec flaw in multicast data protection.
1.3 Configuring GRE
You can configure GRE only after a GRE tunnel is configured.
1.4 Configuring a GRE Tunnel Between CE and PE
Configuring a GRE tunnel between a CE and a PE enables the CE to access the public network
through the GRE tunnel.
1.5 Configuring the Keepalive Function
Before configuring a tunnel policy and a GRE tunnel for the VPN, enable the GRE tunnel
Keepalive function. With this function enabled, the VPN does not select the GRE tunnel that
cannot reach the remote end, and data loss can be avoided.
1.6 Maintaining GRE
This section describes how to reset the statistics of a tunnel interface and monitor the GRE
running status.
1.7 Configuration Examples
Familiarize yourself with the configuration procedures against the networking diagrams. This
section provides networking requirements, configuration notes, and configuration roadmap in
configurations examples.
Issue 02 (2012-03-30)


1 GRE Configuration
1.1 Introduction to GRE

The transmission of packets in a Generic Routing Encapsulation (GRE) tunnel involves two
processes: encapsulation and decapsulation. After receiving a packet of a certain network layer
protocol that needs to be encapsulated and routed, the system adds a GRE header to the packet,
and encapsulates the packet into a packet of another protocol, such as IP.
GRE encapsulates the packets of certain network layer protocols. After encapsulation, these
packets can be transmitted over the network by another network layer protocol, such as IP.
GRE can serve as a Layer 3 tunneling protocol for VPNs. A tunnel is a virtual point-to-point
connection and can be regarded as a virtual interface that supports only point-to-point
connections. This interface provides a path to transmit encapsulated datagrams. GRE
encapsulates and decapsulates datagrams at both ends of the tunnel.
1.2 GRE Features Supported by the AR3200

GRE features supported by the AR3200 include the following: enlargement of the operation
scope of the network running a hop-limited protocol, and working in conjunction with the IP
Security Protocol (IPSec) to compensate for the IPSec flaw in multicast data protection.
Enlarging the Operation Scope of the Network Running a Hop-Limited Protocol

If the hop count between two terminals in Figure 1-1 is more than 15, the two terminals cannot
communicate with each other.
Figure 1-1 Networking diagram of enlarged network operation scope
IP
network
IP
network
IP
network
Tunnel
PC
PC
When the tunnel is used in the network, a few hops are hidden. This enlarges the scope of the
network operation.
Working in Combination with IPSec to Compensate for the IPSec Flaw in Multicast
Data Protection
Based on GRE, multicast data can be encapsulated and transmitted in the GRE tunnel. Based on
IPSec, only the unicast data can realize encrypted protection.
Issue 02 (2012-03-30)


1 GRE Configuration
Figure 1-2 Networking diagram of GRE-IPSec tunnel application
Internet
IPSec tunnel
GRE tunnel
Corporate
intranet
Remote
office
network
As shown in Figure 1-2, if the multicast data is transmitted in the IPSec tunnel, establish the
GRE tunnel and encapsulate the multicast data with GRE. Then encrypt the encapsulated
multicast data with IPSec. When these tasks are performed, the encrypted multicast data can be
transmitted in the IPSec tunnel.
1.3 Configuring GRE

You can configure GRE only after a GRE tunnel is configured.
1.3.1 Establishing the Configuration Task

Before configuring a GRE tunnel, familiarize yourself with the applicable environment,
complete the pre-configuration tasks, and obtain the data required for the configuration.
Applicable Environment
To set up a GRE tunnel, create a tunnel interface first, and configure the GRE functions on the
tunnel interface. If the tunnel interface is deleted, all the configurations on the interface are
deleted.
Pre-configuration Tasks
Before configuring an ordinary GRE tunnel, complete the following task:
l
Configuring reachable routes between the source and destination interfaces
Data Preparation
To configure an ordinary GRE tunnel, you need the following data.
Issue 02 (2012-03-30)
No.
Data
Number of the tunnel interface
Source address and destination address of the tunnel


No.
Data
IP address of the tunnel interface
Key of the tunnel interface
1 GRE Configuration
1.3.2 Configuring a Tunnel Interface

After creating a tunnel interface, specify GRE as the encapsulation type, set the tunnel source
address or source interface, and set the tunnel destination address. In addition, set the tunnel
interface network address so that the tunnel can support dynamic routing protocols.
Context
Perform the following steps on the routers at the two ends of a tunnel.
Procedure
Step 1 Run:
system-view
The system view is displayed.

Step 2 Run:
interface tunnel interface-number
A tunnel interface is created and the tunnel interface view is displayed.

Step 3 Run:
tunnel-protocol gre
The tunnel is encapsulated with GRE.

Step 4 Run:
source { source-ip-address | interface-type interface-number }
The source address or source interface of the tunnel is configured.

NOTE
l The virtual IP address of the VRRP backup group can be configured as the source address of the GRE
tunnel.
l The bridge-if interface can not be configured as the source interface of the GRE tunnel.
The source interface of the tunnel cannot be the interface of the tunnel, but can be specified as
the interface of another tunnel.
Step 5 Run:
destination ip-address
The destination address of the tunnel is configured.

Step 6 (Optional) Run:
mtu mtu
The Maximum Transmission Unit (MTU) of the tunnel interface is modified.

Issue 02 (2012-03-30)


1 GRE Configuration
The new MTU takes effect only after you run the shutdown command and the undo
shutdown command on the interface.
Step 7 Choose one of the following commands to configure the IP address of the tunnel interface.
l Run the ip address ip-address { mask | mask-length } [ sub ] command to configure the IP
address of the tunnel interface.
l Run the ip address unnumbered interface interface-type interface-number command to
configure IP unnumbered for the tunnel interface.
To support dynamic routing protocols on a tunnel, configure a network address for the tunnel
interface. The network address of the tunnel interface may not be a public address, but should
be in the same network segment on both ends of the tunnel.
By default, the network address of a tunnel interface is not set.
----End
1.3.3 Configuring Routes for the Tunnel

Routes for a tunnel must be available on both the source and destination devices so that packets
encapsulated with GRE can be forwarded correctly. A route passing through tunnel interfaces
can be a static route or a dynamic route.
Context
Perform the following steps on the devices at two ends of a tunnel.
NOTE
The packets encapsulated with GRE are forwarded correctly only if the routes for the tunnel are available
on both the source and destination routers.
Procedure
Step 1 Run:
system-view

Step 2 Choose one of the following methods to configure routes passing through the tunnel interface.
l Run the ip route-static ip-address { mask | mask-length } tunnel interface-number
[ description text ] command to configure a static route.
The static route must be configured on both ends of the tunnel. In this command, the
destination address is neither the destination address of the tunnel nor the address of the
opposite tunnel interface, but the destination address of the packet that is not encapsulated
with GRE. The outbound interface must be the local tunnel interface.
l Configure dynamic routes using IGP or BGP. Details for the procedure are not provided here.
For the configuration of dynamic routes, see the AR3200 Configuration Guide - IP
Routing.
When configuring a dynamic routing protocol, enable the dynamic routing protocol on both
the tunnel interface and the interface connected to the private network. To ensure correct
routing, do not choose the tunnel interface as the next hop when configuring the route to the
physical or logical interface of the destination tunnel.
Use Router A in Figure 1-3 as an example. The source interface of Tunnel 0/0/1 is GE 1/0/0
on Router A, and its destination interface is GE 2/0/0 on Router C. If a dynamic routing
Issue 02 (2012-03-30)


1 GRE Configuration
protocol is used, the protocol must be configured on the tunnel interface and the GE interface
connected to the PC. Moreover, in the routing table of Router A, the egress with the
destination as the network segment where GE 2/0/0 on Router C resides cannot be Tunnel
0/0/1.
In practical configurations, configure a multi-process routing protocol or change the metric
value of the tunnel interface. This prevents the tunnel interface from being selected as the
outbound interface of routes to the destination physical interface of the tunnel.
In practical configurations, tunnel interfaces and physical interfaces connected to the public
network should use different routing protocols or different processes of the same routing
protocol. With one of these procedures in place, you can avoid selecting a tunnel interface
as an outbound interface for packets destined for the destination of the tunnel. In addition, a
physical interface is prevented from forwarding user packets that should be forwarded
through the tunnel.
Figure 1-3 Diagram of configuring the GRE dynamic routing protocol
Backbone
GE1/0/0
RouterA
GE2/0/0
RouterC
Tunnel
GE2/0/0 Tunnel0/0/1
Tunnel0/0/2 GE1/0/0
PC1
PC2
----End
1.3.4 (Optional) Configuring GRE Security Options

To enhance the security of a GRE tunnel, configure end-to-end checksum authentication or key
authentication. This security mechanism can prevent the tunnel interface from incorrectly
identifying and receiving packets from other devices.
Context
Perform the following steps on the routers at two ends of a tunnel.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Issue 02 (2012-03-30)


1 GRE Configuration
The tunnel interface view is displayed.

Step 3 Run:
gre checksum
End-to-end checksum authentication is configured for the tunnel.

By default, end-to-end checksum authentication is disabled.
Step 4 Run:
gre key key-number
The key is set for the tunnel interface.

If the keys are set for tunnel interfaces on the two ends of the tunnel, ensure that they have the
same key number. Alternatively, you may choose not to set the keys for tunnel interfaces on
both ends of the tunnel.
By default, no key is configured for the tunnel.
NOTE
Step 3 and Step 4 can be performed in random order.
----End
1.3.5 Checking the Configuration

After a GRE tunnel is set up, you can view the running status and routing information about the
tunnel interface.
Context
The configurations of the GRE function are complete.
Procedure
l
Run the display interface tunnel [ interface-number ] command to check tunnel interface
information.
Run the display ip routing-table command to check the IPv4 routing table.
Run the ping -a source-ip-address host command to check whether the two ends of the
tunnel can successfully ping each other.
----End
Example
Run the display interface tunnel command. If the tunnel interface is Up, the configuration
succeeds. For example:
<Huawei> display interface Tunnel 0/0/1
Tunnel0/0/1 current state : UP
Line protocol current state : UP
Description:HUAWEI, AR Series, Tunnel0/0/1 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet Address is 5.5.5.2/24
Encapsulation is TUNNEL, loopback not set
Tunnel source 150.1.1.1 (Ethernet4/0/0), destination 150.1.1.2
Tunnel protocol/transport GRE/IP, key disabled
keepalive disabled
Checksumming of packets disabled
Issue 02 (2012-03-30)


1 GRE Configuration
Current system time: 2008-03-04 19:17:30

300 seconds input rate 0 bits/sec, 0 packets/sec
300 seconds output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes
0 input error
0 packets output, 0 bytes
0 output error
Input bandwidth utilization : -Output bandwidth utilization : --
Run the display ip routing-table command. If the route passing through the tunnel interface
exists in the routing table, the configuration succeeds. For example:
[Huawei] display ip routing-table
Route Flags: R - relay, D - download to fib
-----------------------------------------------------------------------------Routing Tables: Public
Destinations : 8
Routes : 8
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24 Direct 0
0
D 10.1.1.2
GigabitEthernet2/0/0
10.1.1.2/32 Direct 0
0
D 127.0.0.1
InLoopBack0
10.2.1.0/24 Static 60
0
D 40.1.1.1
Tunnel0/0/2
20.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
40.1.1.0/24 Direct 0
0
D 40.1.1.1
Tunnel0/0/2
40.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
Run the ping -a source-ip-address host command to see that the ping from the local tunnel
interface to the destination tunnel succeeds.
<Huawei> ping -a 40.1.1.1 40.1.1.2
PING 40.1.1.2: 56 data bytes, press CTRL_C to break
Reply from 40.1.1.2: bytes=56 Sequence=1 ttl=255 time=24
--- 40.1.1.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 24/34/48 ms
ms
ms
ms
ms
ms
1.4 Configuring a GRE Tunnel Between CE and PE

Configuring a GRE tunnel between a CE and a PE enables the CE to access the public network

Before configuring a GRE tunnel between a CE and a PE, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the required data. This can help
you complete the configuration task quickly and accurately.
To allow users of the CE that is not directly connected with a PE to access the Multi-Protocol
Label Switching (MPLS) VPN, configure a GRE tunnel, create routes between them, and
configure MPLS VPN on the PE.
Issue 02 (2012-03-30)


1 GRE Configuration
A GRE tunnel needs to be created between a CE and a PE in the following two cases:
l
A CE interconnects with a PE through the public network.
A CE interconnects with a PE through the VPN of a second carrier.
Before configuring a GRE tunnel between a CE and a PE, complete the following tasks:
l
Assigning IP addresses for interfaces on the CE and PE
Configuring the routes between the CE and PE
Configuring the VPN provided that it is also passed through by the GRE tunnel between
the CE and PE
Data Preparation
To configure a GRE tunnel between a CE and a PE, you need the following data.
No.
Data
Number of the GRE tunnel interface specified on the CE
Source address or source interface and destination address of the GRE tunnel interface
specified on the CE
Number of the GRE tunnel interface specified on the PE
Source address or source interface and destination address of the GRE tunnel interface
specified on the PE
Name of the VPN provided that it is also passed through by the GRE tunnel between
the CE and PE
1.4.2 Configuring the GRE Tunnel Interface on CE

After creating a tunnel interface on a CE, specify GRE as the encapsulation type, set the tunnel
source address or source interface, and set the tunnel destination address. The source address of
the tunnel specified on the CE is the destination address of the tunnel specified on the PE. The
destination address of the tunnel specified on the CE is the source address of the tunnel specified
on the PE.
Context
Perform the following steps on the CE.
Procedure
Step 1 Run:
system-view

Issue 02 (2012-03-30)


1 GRE Configuration
Step 2 Run:
The tunnel interface is created and the tunnel interface view is displayed.
Step 3 Run:
tunnel-protocol gre
The tunnel is encapsulated as a GRE tunnel.

Step 4 Run:
The source address or source interface of the tunnel interface is configured.

NOTE
tunnel.
The source address of the tunnel specified on the CE is identical with the destination address of
the tunnel specified on the PE. The destination address of the tunnel specified on the CE is
identical with the source address of the tunnel specified on the PE.
Step 5 Run:
The destination address of the tunnel interface is configured.

mtu mtu
The interface MTU can be modified. The new MTU takes effect only after you run the
shutdown and the undo shutdown commands in succession on the interface.
----End
1.4.3 Configuring the GRE Tunnel Interface on PE

After creating a tunnel interface on a PE, specify GRE as the encapsulation type, set the tunnel
source address or source interface, and set the tunnel destination address. The source address of
the tunnel specified on the PE is the destination address of the tunnel specified on the CE. The
destination address of the tunnel specified on the PE is the source address of the tunnel specified
on the CE.
Context
Perform the following steps on the PE.
Issue 02 (2012-03-30)

10

1 GRE Configuration
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
tunnel-protocol gre
The tunnel is encapsulated as a GRE tunnel.

Step 4 Run:
The source address or source interface of the tunnel interface is configured.

NOTE
tunnel.
The source address of the tunnel specified on the PE is identical with the destination address of
the tunnel specified on the CE. The destination address of the tunnel specified on the PE is
identical with the source address of the tunnel specified on the CE.
Step 5 Run:
The destination address of the tunnel interface is configured.

mtu mtu
The interface MTU is modified. The new MTU takes effect only after you run the shutdown
and the undo shutdown commands in succession on the interface.
----End
Issue 02 (2012-03-30)

11

1 GRE Configuration
1.4.4 Binding the GRE Tunnel with the VPN to Which CE belongs
on PE
Bind the tunnel interface on the PE that connects the CE to a VPN instance. Then, the tunnel
interface becomes a VPN interface. The packets sent from the VPN interface are forwarded
based on forwarding information in the VPN instance.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
The tunnel interface is created and the tunnel interface view is displayed.
Step 3 Run:
ip binding vpn-instance vpn-instance-name
Bind the GRE tunnel with the VPN instance.

NOTE
The running of the ip binding vpn-instance command on a tunnel interface can delete the Layer 3 attributes,
such as the IP address and routing protocol. If these Layer 3 attributes are still required, configure them
again.
A tunnel interface cannot be bound to any VPN instance that is not enabled with an address family.
Disabling a VPN instance address family deletes the Layer 3 attributes, such as the IP address and routing
protocol of the tunnel interface bound to the VPN instance. Disabling all VPN instance address families
unbinds all the bound tunnel interfaces from the VPN instance.
l Run the ip address ip-address { mask | mask-length } [ sub ] command to assign an IP address
to the tunnel interface.
----End

After a GRE tunnel is set up between a CE and a PE, you can view routes to a specified VPN.
Prerequisites
The GRE tunnel between the CE and the PE is fully configured.
Issue 02 (2012-03-30)

12

1 GRE Configuration
Procedure
l
Run the display interface tunnel [ interface-number ] command to check the working
mode of the tunnel interface.
Run the display ip routing-table vpn-instance vpn-instance-name command to check the

VPN routing table on the PE.
Run the display ip routing-table command to check the routing table on the CE.
Run the ping -a source-ip-address host command to check whether two ends of the tunnel
can successfully ping each other.
----End
Example
Run the display interface tunnel command on two ends of the tunnel. If the tunnel interface is
Up, the configuration is successful. Take the display on the PE as an example:
<Huawei> display interface Tunnel 0/0/1
Tunnel0/0/1 current state : UP
Line protocol current state : UP
Last line protocol up time : 2008-03-03 10:51:44
Description:HUAWEI, AR Series, Tunnel0/0/1 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet Address is 5.5.5.2/24
Encapsulation is TUNNEL, loopback not set
Tunnel source 150.1.1.1 (Ethernet4/0/0), destination 150.1.1.2
Tunnel protocol/transport GRE/IP, key disabled
keepalive disabled
Checksumming of packets disabled
Current system time: 2008-03-04 19:17:30
0 packets input, 0 bytes
0 input error
0 packets output, 0 bytes
0 output error
Input bandwidth utilization : -Output bandwidth utilization : --
1.5 Configuring the Keepalive Function

Before configuring a tunnel policy and a GRE tunnel for the VPN, enable the GRE tunnel
Keepalive function. With this function enabled, the VPN does not select the GRE tunnel that
cannot reach the remote end, and data loss can be avoided.

Before configuring the GRE tunnel Keepalive function, familiarize yourself with the applicable
Application Environment
The Keepalive function can be configured on one end of a GRE tunnel to test the GRE tunnel
status. If the remote end is found unreachable, the tunnel is disconnected on time to avoid data
black hole.
Issue 02 (2012-03-30)

13

1 GRE Configuration
Figure 1-4 GRE tunnel supporting Keepalive

Internet
Source
Destination
GRE tunnel
RouterA
RouterB
Before configuring the Keepalive function, complete the following tasks:
l
Configuring the link layer attributes of the interfaces
Assigning IP addresses to the interfaces
Establishing the GRE tunnel and keeping the tunnel Up
Data Preparation
To configure the Keepalive function, you need the following data.
No.
Data
Interval for sending Keepalive messages
Retry times of the unreachable timer
1.5.2 Enabling the Keepalive Function

The GRE tunnel Keepalive function is unidirectional. To implement the Keepalive function on
both ends, enable the Keepalive function on both ends of a GRE tunnel.
Context
Perform the following steps on the router that requires the Keepalive function.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
tunnel-protocol gre
Issue 02 (2012-03-30)

14

1 GRE Configuration
The tunnel is encapsulated with GRE.

Step 4 Run:
keepalive [ period period [ retry-times retry-times ] ]
The Keepalive function is enabled.

The GRE tunnel Keepalive function is unidirectional. Therefore, to realize the Keepalive
function on both ends, enable the Keepalive function on both ends of a GRE tunnel. One end
can be configured with the Keepalive function regardless of whether the remote end is enabled
with the Keepalive function. But it is still recommended to enable the Keepalive function on
both ends of the GRE tunnel.
TIP
Before configuring the tunnel policy and the GRE tunnel for the VPN, enable the GRE tunnel Keepalive
function. With this function enabled, the VPN does not select the GRE tunnel that cannot reach the remote
end, and the data loss can be avoided. The reasons for enabling the Keepalive function are listed below:
l If the Keepalive function is not enabled, the local tunnel interface may always be Up regardless of
whether data reaches the remote end.
l If the Keepalive function is enabled on the local end, the local tunnel interface is set Down when the
remote end is unreachable. As a result, the VPN does not select the unreachable GRE tunnel and the
data is not lost.
----End

After a GRE tunnel is enabled with the Keepalive function, you can view the Keepalive packets
and Keepalive Response packets sent and received by the GRE tunnel interfaces.
Prerequisites
The Keepalive function is enabled on the GRE tunnel.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
display keepalive packets count
Check the Keepalive packets and Keepalive Response packets sent and received by the GRE
tunnel interface.
----End
Example
On the tunnel interface that is enabled with the Keepalive function, run the display keepalive
packets count command to ascertain the number of sent Keepalive packets and received
Issue 02 (2012-03-30)

15

1 GRE Configuration
Keepalive Response packets on both the local end and the remote end. If the Keepalive function
is successfully configured on the local tunnel interface, the number of sent Keepalive packets
or received Keepalive Response packets on the local end is not 0.
[Huawei] interface tunnel 0/0/1
[Huawei-Tunnel0/0/1] tunnel-protocol gre
[Huawei-Tunnel0/0/1] keepalive
[Huawei-Tunnel0/0/1] display keepalive packets count
Send 34 keepalive packets to peers, Receive 34 keepalive response packets from peers
Receive 0 keepalive packets from peers, Send 0 keepalive response packets to peers.
1.6 Maintaining GRE

This section describes how to reset the statistics of a tunnel interface and monitor the GRE
running status.
1.6.1 Resetting the Statistics of a Tunnel Interface

When you need to reset the statistics of a tunnel interface, you can run the reset commands to
clear the Keepalive packets and Keepalive Response packets sent and received by a GRE tunnel
interface.
Procedure
l
Run the reset counters interface tunnel [ interface-number ] command in the system view
to reset statistics about the tunnel interface.
Reset statistics about Keepalive packets on the tunnel interface.

1.
Run:
system-view

2.
Run:

3.
Run:
reset keepalive packets count
Reset the statistics on Keepalive packets on the tunnel interface.

NOTE
You can run the reset keepalive packets count command only in the tunnel interface view,
and the interface tunnel protocol must be GRE.
----End
1.6.2 Monitoring the Running Status of GRE

In routine maintenance, you can run the GRE related display commands to view the GRE running
status.
Context
In routine maintenance, you can run the following commands to view the GRE running status.
Issue 02 (2012-03-30)

16

1 GRE Configuration
Procedure
l
Run the display interface tunnel [ interface-number ] command to check the tunnel
interface running status.

Run the ping [ -a source-ip-address | -vpn-instance vpn-instance-name ] * host command

to check whether the two ends of the tunnel can communicate with each other.
----End
1.6.3 Debugging GRE

When a GRE fault occurs, you can run the L2TP related debugging commands to debug GRE
and locate the fault.
Context
NOTE
The debugging process affects system performance. Therefore, after finishing the debugging process, run
the undo debugging all command immediately to disable the debugging.
When GRE goes abnormal, run the debugging commands in the user view to view debugging
information, locate the fault, and analyze the cause.
Procedure
l
Run the debugging tunnel keepalive command in the user view to debug the Keepalive
function of the GRE tunnel.
----End

Familiarize yourself with the configuration procedures against the networking diagrams. This
section provides networking requirements, configuration notes, and configuration roadmap in
configurations examples.
1.7.1 Example for Configuring a Static Route for GRE

This section provides an example for configuring a static route for GRE. In this networking,
traffic between users is transmitted through a GRE tunnel; a static route is configured between
the device and its connected client.
Networking Requirements
In Figure 1-5, Router A, Router B, and Router C belong to the VPN backbone network and
OSPF runs between them.
GRE is enabled between Router A and Router C to achieve interworking between PC 1 and PC
2.
PC1 takes Router A as its default gateway, and PC2 takes Router C as its default gateway.
Issue 02 (2012-03-30)

17

1 GRE Configuration
Figure 1-5 Networking diagram of configuring a static route for GRE
RouterB
GE1/0/0
20.1.1.2/24
RouterA
GE2/0/0
30.1.1.1/24
GE1/0/0
GE1/0/0
30.1.1.2/24
20.1.1.1/24
Tunnel
GE2/0/0 Tunnel0/0/1
10.1.1.2/24 40.1.1.1/24
PC1
10.1.1.1/24
RouterC
Tunnel0/0/1 GE2/0/0
40.1.1.2/24 10.2.1.2/24
PC2
10.2.1.1/24
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure a dynamic routing protocol on routers.
2.
Create a tunnel interface on Router A and Router C.
3.
Specify the source address of the tunnel interface as the IP address of the interface that
sends the packet.
4.
Specify the destination address of the tunnel interface as the IP address of the interface that
receives the packet.
5.
Assign network addresses to the tunnel interfaces to enable the tunnel to support the
dynamic routing protocol.
6.
Configure the static route between Router A and its connected PC, and the static route
between Router C and its connected PC to make the traffic between PC1 and PC2
transmitted through the GRE tunnel.
7.
Configure the egress of the static route as the local tunnel interface.
Data Preparation
To complete the configuration, you need the following data:
l
Data for running OSPF
Source address and destination address of the GRE tunnel, and IP addresses of tunnel
interfaces
Procedure
Step 1 Assign an IP address to each interface.
Issue 02 (2012-03-30)

18

1 GRE Configuration
Assign an IP address to each interface as shown in Figure 1-5. The specific configuration is not
mentioned here.
Step 2 Configure IGP for the VPN backbone network.
# Configure Router A.
[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
# Configure Router B.
[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] network 30.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterB-ospf-1] quit
# Configure Router C.
[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, run the display ip routing-table command on Router A and Router C.
You can find that they both learn the OSPF route to the network segment of the remote interface.
Take Router A as an example.
[RouterA] display ip routing-table
Destinations : 8
Routes : 8
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
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
InLoopBack0
20.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
30.1.1.0/24 OSPF
10
2
D 20.1.1.2
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
Step 3 Configure the tunnel interface.

[RouterA] interface tunnel 0/0/1
[RouterA-Tunnel0/0/1] ip address 40.1.1.1 24
[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] ip address 40.1.1.2 24
[RouterC-Tunnel0/0/1] source 30.1.1.2
[RouterC-Tunnel0/0/1] destination 20.1.1.1
[RouterC-Tunnel0/0/1] quit
Issue 02 (2012-03-30)

19

1 GRE Configuration
After the configuration, the status of tunnel interfaces goes Up, and the tunnel interfaces can
ping each other successfully.
Take Router A as an example:
[RouterA] ping -a 40.1.1.1 40.1.1.2
0.00% packet loss
ms
ms
ms
ms
ms
Step 4 Configure a static route.

[RouterA] ip route-static 10.2.1.0 24 tunnel 0/0/1
[RouterC] ip route-static 10.1.1.0 24 tunnel 0/0/1
After the configuration, run the displayip routing-table command on Router A and Router C.
You can find the static route to the network segment of the remote user end through the tunnel
interface.
Destinations : 11
Routes : 11
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
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
InLoopBack0
10.2.1.0/24 Static 60
0
D 40.1.1.1
Tunnel0/0/1
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
InLoopBack0
20.1.1.2/32 Direct 0
0
D 20.1.1.2
30.1.1.0/24 OSPF
10
2
D 20.1.1.2
40.1.1.0/24 Direct 0
0
D 40.1.1.1
Tunnel0/0/1
40.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
PC 1 and PC 2 can ping each other successfully.

----End
Configuration Files
l
Configuration file of Router A

#
sysname RouterA
#
interface GigabitEthernet1/0/0
Issue 02 (2012-03-30)

20

1 GRE Configuration
ip address 20.1.1.1 255.255.255.0

#
ip address 10.1.1.2 255.255.255.0
#
interface Tunnel0/0/1
ip address 40.1.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
Configuration file of Router B

#
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
Configuration file of Router C

#
sysname RouterC
#
ip address 30.1.1.2 255.255.255.0
#
ip address 10.2.1.2 255.255.255.0
#
ip address 40.1.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
1.7.2 Example for Configuring a Dynamic Routing Protocol for GRE

This section provides an example for configuring a dynamic route for GRE. In this networking,
traffic between users is transmitted through a GRE tunnel; a dynamic route is configured between
the device and its connected user.
Issue 02 (2012-03-30)

21

1 GRE Configuration
In Figure 1-6, Router A, Router B, and Router C belong to the VPN backbone network and
OSPF runs between them.
GRE is enabled between Router A and Router C for the interworking between PC1 and PC2.
PC1 takes Router A as its default gateway, and PC2 takes Router C as its default gateway.
OSPF is enabled on the tunnel interface. OSPF process 1 is used for the VPN backbone network
and OSPF process 2 is used for user access.
Figure 1-6 Networking diagram of configuring a dynamic routing protocol for GRE
RouterB
GE1/0/0
GE2/0/0
20.1.1.2/24
30.1.1.1/24
OSPF 1
RouterA
RouterC
Tunnel
GE2/0/0
10.1.1.2/24
10.1.1.1/24
GE1/0/0
30.1.1.2/24
GE1/0/0
20.1.1.1/24
Tunnel0/0/1 OSPF 2
40.1.1.1/24
Tunnel0/0/1
40.1.1.2/24
GE2/0/0
10.2.1.2/24
10.2.1.1/24
PC1
PC2
1.
Configure IGP on each router in the backbone network to realize the interworking between
these devices. Here OSPF process 1 is used.
2.
Create the GRE tunnel between routers that are connected to PCs.Then routers can
communicate through the GRE runnel.
3.
Configure the dynamic routing protocol on the network segments through which PCs access
the backbone network. Here OSPF process 2 is used.
Data Preparation
l
Issue 02 (2012-03-30)
Source address and destination address of the GRE tunnel

22

1 GRE Configuration
IP addresses of the interfaces on both ends of the GRE tunnel
Procedure
mentioned here.
Step 2 Configure IGP for the VPN backbone network.
The specific configuration procedures are the same as those in 1.7.1 Example for Configuring
a Static Route for GRE and are not mentioned here.
Step 3 Configuring the tunnel interfaces
The specific configuration procedures are the same as those in 1.7.1 Example for Configuring
a Static Route for GRE and are not mentioned here.
Step 4 Configure OSPF on the tunnel interfaces.
[RouterA] ospf 2
[RouterA-ospf-2] area 0
[RouterA-ospf-2-area-0.0.0.0] quit
[RouterA-ospf-2] quit
[RouterC] ospf 2
[RouterC-ospf-2] area 0
[RouterC-ospf-2-area-0.0.0.0] quit
[RouterC-ospf-2] quit
Step 5 Verify the configuration.

After the configuration, run the display ip routing-table command on Router A and Router C.
You can find the OSPF route to the network segment of the remote user end through the tunnel
interface. Moreover, the next hop to the destination physical address (30.1.1.0/24) of the tunnel
is not the tunnel interface.
Destinations : 11
Routes : 11
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
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
InLoopBack0
10.2.1.0/24 OSPF
10
2
D 40.1.1.2
Tunnel0/0/1
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
InLoopBack0
30.1.1.0/24 OSPF
10
2
D 20.1.1.2
40.1.1.0/24 Direct 0
0
D 40.1.1.1
Tunnel0/0/1
40.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
Issue 02 (2012-03-30)

23

127.0.0.0/8
127.0.0.1/32
1 GRE Configuration
Direct 0
Direct 0
0
0
D
D
127.0.0.1
127.0.0.1
InLoopBack0
InLoopBack0
PC 1 and PC 2 can ping each other successfully.

----End
Configuration Files
l

#
sysname RouterA
#
ip address 20.1.1.1 255.255.255.0
#
ip address 10.1.1.2 255.255.255.0
#
ip address 40.1.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
#
ospf 2
area 0.0.0.0
network 40.1.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 40.1.1.2 255.255.255.0
tunnel-protocol gre
source 30.1.1.2
Issue 02 (2012-03-30)

24

1 GRE Configuration
#
ospf 1
area 0.0.0.0
network 30.1.1.0 0.0.0.255
#
ospf 2
area 0.0.0.0
network 40.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
return
1.7.3 Example for Configuring a GRE Tunnel to Transmit VPN

Multicast Data Encrypted with IPSec
This section provides an example for configuring a GRE tunnel to transmit multicast packets
encrypted with IPSec. In this networking, a GRE tunnel is set up between devices; multicast
packets are encapsulated with GRE and then IPSec.
In Figure 1-7, Router A and Router C are required to transmit multicast packets, and the multicast
packets must be encrypted through IPSec. Before being encrypted through IPSec, multicast
packets must be encapsulated with GRE because IPSec cannot directly encrypt multicast packets.
Figure 1-7 Networking diagram of transmitting IPSec-encrypted multicast packets through a
GRE tunnel
RouterB
GE1/0/0
20.1.1.2/24
RouterA
GE2/0/0
30.1.1.1/24
GE1/0/0
GE1/0/0
30.1.1.2/24
20.1.1.1/24
GRE with IPSec
RouterC
GE2/0/0 Tunnel0/0/1
10.1.1.2/24 40.1.1.1/24
Tunnel0/0/1 GE2/0/0
40.1.1.2/24 10.2.1.2/24
10.1.1.1/24
10.2.1.1/24
1.
Configure OSPF on the backbone network devices, namely, Router A, Router B, and
Router C, to realize the interworking between these devices.
2.
Create a GRE tunnel between Router A and Router C to encapsulate multicast packets.
Issue 02 (2012-03-30)

25

3.
1 GRE Configuration
Create an IPSec tunnel between Router A and Router C to encrypt the GRE encapsulated
multicast packets.
Data Preparation
l
Data for configuring the routing protocol for the backbone network
IP addresses of the interfaces on both ends of the GRE tunnel
Parameters for configuring IKE such as pre-shared-key and remote-name
Data for configuring IPSec such as IPSec proposal name and ACL
Procedure
Step 1 Configure the routing protocol.
Configure a routing protocol on Router A, Router B, and Router C to implement the interworking
between these devices. OSPF is configured in this example. The configuration details are not
mentioned here.
After the configuration,
l Router A and Router C are routable.
l Router A can successfully ping GE1/0/0 of Router C.
l Router C can successfully ping GE1/0/0 of Router A.
Step 2 Configure the interfaces of the GRE tunnel.
[RouterA] interface tunnel0/0/1
[RouterA-Tunnel0/0/1] ip address 40.1.1.1 255.255.255.0
[RouterA-Tunnel0/0/1] tunnel-protocol gre
[RouterC] interface tunnel0/0/1
[RouterC-Tunnel0/0/1] ip address 40.1.1.2 255.255.255.0
[RouterC-Tunnel0/0/1] tunnel-protocol gre
[RouterC-Tunnel0/0/1] source 30.1.1.2
[RouterC-Tunnel0/0/1] destination 20.1.1.1
After the configuration,

l The GRE tunnel between Router A and Router C is set up.
l The status of the tunnel interfaces is Up.
Step 3 Enable multicast.
# Enable the multicast routing protocol globally. Enable PIM DM on the tunnel interfaces, and
enable PIM DM and IGMP on the interfaces connected to the PCs.
[RouterA] multicast routing-enable
Issue 02 (2012-03-30)

26

1 GRE Configuration
[RouterA] interface gigabitethernet 2/0/0

[RouterA-GigabitEthernet2/0/0] pim dm
[RouterA-GigabitEthernet2/0/0] igmp enable
[RouterA-GigabitEthernet2/0/0] quit
[RouterA] interface tunnel0/0/1
[RouterA-Tunnel0/0/1] pim dm
[RouterC] multicast routing-enable
[RouterC] interface gigabitethernet 2/0/0
[RouterC-GigabitEthernet2/0/0] pim dm
[RouterC-GigabitEthernet2/0/0] igmp enable
[RouterC-GigabitEthernet2/0/0] quit
[RouterC] interface tunnel0/0/1
[RouterC-Tunnel0/0/1] pim dm
# After multicast is enabled, the multicast data between Router A and Router C is transmitted
Step 4 Configure aggressive IKE negotiation between Router A and Router C.
NOTE
To encapsulate multicast packets with GRE and then encrypt the multicast packets with IPSec, the remote
address in IKE peer mode must be the destination address of the local tunnel.
[RouterA] ike local-name rta
[RouterA] ike peer RouterC v1
[RouterA-ike-peer-routerc] exchange-mode aggressive
[RouterA-ike-peer-routerc] local-id-type name
[RouterA-ike-peer-routerc] pre-shared-key 12345
[RouterA-ike-peer-routerc] remote-name rtc
[RouterA-ike-peer-routerc] remote-address 30.1.1.2
[RouterA-ike-peer-routerc] quit
[RouterC] ike local-name rtc
[RouterC] ike peer RouterA v1
[RouterC-ike-peer-routera] exchange-mode aggressive
[RouterC-ike-peer-routera] local-id-type name
[RouterC-ike-peer-routera] pre-shared-key 12345
[RouterC-ike-peer-routera] remote-name rta
[RouterC-ike-peer-routera] remote-address 20.1.1.1
[RouterC-ike-peer-routera] quit
Step 5 Configure IPSec.

NOTE
Encapsulate multicast packets with GRE and then encrypt these packets with IPSec. Note that the source
and destination addresses for the local end of the tunnel must match the ACL of the IPSec policy, and the
IPSec policy must be applied to the physical interface transmitting data.
# Configure IPSec on Router A and Router C. The default parameters of the IPSec proposal is
used in this example.
[RouterA] acl number 3000
[RouterA-acl-adv-3000] rule permit gre source 20.1.1.1 0 destination 30.1.1.2 0
[RouterA-acl-adv-3000] quit
[RouterA] ipsec proposal p1
[RouterA-ipsec-proposal-p1] quit
Issue 02 (2012-03-30)

27

1 GRE Configuration
[RouterA] ipsec policy policy1 1 isakmp

[RouterA-ipsec-policy-isakmp-policy1-1] security acl 3000
[RouterA-ipsec-policy-isakmp-policy1-1] ike-peer RouterC
[RouterA-ipsec-policy-isakmp-policy1-1] proposal p1
[RouterA-ipsec-policy-isakmp-policy1-1] quit
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ipsec policy policy1
[RouterA-GigabitEthernet1/0/0] quit
[RouterC] acl number 3000
[RouterC-acl-adv-3000] rule permit gre source 30.1.1.2 0 destination 20.1.1.1 0
[RouterC-acl-adv-3000] quit
[RouterC] ipsec proposal p1
[RouterC-ipsec-proposal-p1] quit
[RouterC] ipsec policy policy1 1 isakmp
[RouterC-ipsec-policy-isakmp-policy1-1] security acl 3000
[RouterC-ipsec-policy-isakmp-policy1-1] ike-peer RouterA
[RouterC-ipsec-policy-isakmp-policy1-1] proposal p1
[RouterC-ipsec-policy-isakmp-policy1-1] quit
[RouterC] interface gigabitethernet 1/0/0
[RouterC-GigabitEthernet1/0/0] ipsec policy policy1
[RouterC-GigabitEthernet1/0/0] quit
# After the configuration, the multicast data between Router A and Router C can be transmitted
through the GRE tunnel encrypted with IPSec.
Step 6 On the source device and the destination device of the tunnel, configure the tunnel to forward
routes.
[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

# After PC1 and PC2 successfully ping each other, you can view that IKE negotiation is
configured and IPSec encryption takes effect.
[RouterA] display ike sa
Conn-ID Peer
VPN
Flag(s)
Phase
--------------------------------------------------------------16
30.1.1.2
0
RD
1
17
30.1.1.2
0
RD
2
Flag Description:
RD--READY
ST--STAYALIVE
RL--REPLACED
FD--FADING
TO--TIMEOUT
HRT--HEARTBEAT
LKG--LAST KNOWN GOOD SEQ NO.
BCK--BACKED UP
[RouterA] display ips sa
===============================
Interface: GigabitEthernet1/0/0
path MTU: 1500
===============================
----------------------------IPsec policy name: "policy1"
sequence number: 1
mode: isakmp
----------------------------connection id: 17
encapsulation mode: tunnel
tunnel local : 20.1.1.1
tunnel remote: 30.1.1.2
[inbound ESP SAs]
spi: 2970386335 (0xb10c7f9f)
proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5
Issue 02 (2012-03-30)

28

1 GRE Configuration
sa remaining key duration (bytes/sec): 1887434624/3081

max received sequence-number: 32
udp encapsulation used for nat traversal: N
[outbound ESP SAs]
spi: 1720763150 (0x6690c30e)
max sent sequence-number: 33
[RouterC] display ike sa
Conn-ID Peer
VPN
Flag(s)
Phase
--------------------------------------------------------- ---20
20.1.1.2
0
RD|ST
1
21
20.1.1.2
0
RD|ST
2
Flag Description:
RD--READY
ST--STAYALIVE
RL--REPLACED
FD--FADING
TO--TIMEOUT
HRT--HEARTBEAT
BCK--BACKED UP
[RouterC] display ips sa
===============================
Interface: GigabitEthernet1/0/0
path MTU: 1500
===============================
----------------------------IPsec policy name: "policy1"
sequence number: 1
mode: isakmp
----------------------------connection id: 21
tunnel local : 30.1.1.2
[inbound ESP SAs]
spi: 1720763150 (0x6690c30e)
[outbound ESP SAs]
spi: 2970386335 (0xb10c7f9f)
----End
Configuration Files
l

#
sysname RouterA
#
ike local-name rta
#
multicast routing-enable
#
acl number 3000
rule 5 permit gre source 20.1.1.1 0.0.0.0 destination 30.1.1.2 0.0.0.0
#
ike peer routerc v1
exchange-mode aggressive
pre-shared-key 12345
local-id-type name
remote-name rtc
remote-address 30.1.1.2
#
ipsec proposal p1
#
Issue 02 (2012-03-30)

29

1 GRE Configuration
ipsec policy policy1 1 isakmp

security acl 3000
ike-peer Routerc
proposal p1
#
ip address 20.1.1.1 255.255.255.0
ipsec policy policy1
#
ip address 10.1.1.2 255.255.255.0
pim dm
igmp enable
#
ip address 40.1.1.1 255.255.255.0
tunnel-protocol gre
source 20.1.1.1
pim dm
#
ospf 1
area 0.0.0.0
network 20.1.1.1 0.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
#
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
#
ike local-name rtc
#
multicast routing-enable
#
acl number 3000
rule 5 permit gre source 30.1.1.2 0.0.0.0 destination 20.1.1.1 0.0.0.0
#
ike peer routera v1
exchange-mode aggressive
pre-shared-key 12345
local-id-type name
remote-name rta
#
ipsec proposal p1
#
ipsec policy policy1 1 isakmp
security acl 3000
ike-peer Routera
proposal p1
Issue 02 (2012-03-30)

30

1 GRE Configuration
#
ip address 30.1.1.2 255.255.255.0
#
ip address 10.2.1.2 255.255.255.0
pim dm
igmp enable
#
ip address 40.1.1.2 255.255.255.0
tunnel-protocol gre
source 30.1.1.2
pim dm
#
ospf 1
area 0.0.0.0
network 30.1.1.2 0.0.0.0
#
#
return
1.7.4 Example for Configuring the CE to Access a VPN Through a

GRE Tunnel of the Public Network
This section provides an example for configuring a CE to access a VPN through a GRE tunnel
on the public network. In this networking, the PE is indirectly connected to the CE; thus, no
physical interface can be bound to the VPN instance on the PE. Then, a GRE tunnel over the
public network is required between the CE and PE and the GRE tunnel is required to be bound
to the VPN instance on the PE. This allows the CE to access the VPN through the GRE tunnel.
As shown in Figure 1-8,
l
routerPE1 and PE2 are located in the MPLS backbone network.
CE1 is connected to PE1 through R1.
CE2 is connected to PE2 directly.
CE1 and CE2 belong to the same VPN.
CE1 and CE2 are required to interwork with each other.
Issue 02 (2012-03-30)

31

1 GRE Configuration
Figure 1-8 Networking diagram in which CEs access a VPN through the GRE tunnel of the
public network
Loopback1
MPLS
R1
GE2/0/0
T
CE1
GE2/0/0
GE1/0/0
GE2/0/0
GE1/0/0
Loopback1
el
unn
GE1/0/0
PE1
Tunnel0/0/1
PE2
GE2/0/0
CE2
GE1/0/0
GE2/0/0
Tunnel0/0/1
GE1/0/0
PC2
PC1
Router
Interface
IP address
CE1
GE1/0/0
21.1.1.2/24
CE1
GE2/0/0
30.1.1.1/24
CE1
Tunnel0/0/1
2.2.2.1/24
R1
GE1/0/0
30.1.1.2/24
R1
GE2/0/0
50.1.1.1/24
PE1
Loopback1
1.1.1.9/32
PE1
GE1/0/0
50.1.1.2/24
PE1
GE2/0/0
110.1.1.1/24
PE1
Tunnel0/0/1
2.2.2.2/24
PE2
Loopback1
3.3.3.9/32
PE2
GE1/0/0
110.1.1.2/24
PE2
GE2/0/0
11.1.1.2/24
CE2
GE1/0/0
11.1.1.1/24
CE2
GE2/0/0
41.1.1.2/24
PE1 and CE1 are indirectly connected. So the VPN instance on PE1 cannot be bound to the
physical interface on PE1. In such a situation, a GRE tunnel is required between CE1 and PE1.
vpn1 on PE1 can then be bound to the GRE tunnel, and CE1 can access the VPN through the
GRE tunnel.
1.
Configure OSPF10 on PE1 and PE2 to implement the interworking between the two
devices, and then enable MPLS.
2.
Configure OSPF20 on CE1, R1, and PE1 to implement the interworking between the three
devices.
3.
Establish a GRE tunnel between CE1 and PE1.
Issue 02 (2012-03-30)

32

1 GRE Configuration
4.
Create VPN instances on PE1 and PE2. Then bind the VPN instance on PE1 to the GRE
tunnel interface, and bind the VPN instance on PE2 to the connected physical interface of
CE2.
5.
Configure IS-IS routes between CE1 and PE1, and between CE2 and PE2 to implement
the interworking between the CEs and PEs.
6.
Configure BGP on PEs to implement the interworking between CE1 and CE2.
Data Preparation
l
IP addresses of the interfaces, process ID of the routing protocol, and AS number
VPN instance names, RDs, and VPN targets on PEs
Procedure
Step 1 Configure the IP address for each interface and the routing protocol for the MPLS backbone
network.
Configure OSPF10 on PE1 and PE2, and then configure MPLS and LDP. The detailed
configurations are not mentioned here.
Step 2 Configure a routing protocol between CE1, R1, and PE1.
Configure OSPF20 on CE1, R1, and PE1. The detailed configurations are not mentioned here.
Step 3 Establish a GRE tunnel between CE1 and PE1.
# Configure CE1.
[CE1] interface tunnel0/0/1
[CE1-Tunnel0/0/1] ip address 2.2.2.1 255.255.255.0
[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
# Configure PE1.
[PE1] interface tunnel0/0/1
[PE1-Tunnel0/0/1] ip address 2.2.2.2 255.255.255.0
[PE1-Tunnel0/0/1] tunnel-protocol gre
[PE1-Tunnel0/0/1] source 50.1.1.2
[PE1-Tunnel0/0/1] destination 30.1.1.1
# After the configuration, a GRE tunnel is established between CE1 and PE1.
Step 4 Create a VPN instance named vpn1 on PE1 and bind the VPN instance to the GRE tunnel.
[PE1]ip vpn-instance vpn1
[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-vpn-instance-vpn1-af-ipv4] quit
[PE1-vpn-instance-vpn1] quit
[PE1-Tunnel0/0/1] ip binding vpn-instance vpn1
[PE1-Tunnel0/0/1] ip address 2.2.2.2 255.255.255.0
Step 5 Create a VPN instance named vpn1 on PE2 and bind the VPN instance to the GE interface.
[PE2]ip vpn-instance vpn1
[PE2-vpn-instance-vpn1] route-distinguisher 200:1
Issue 02 (2012-03-30)

33

1 GRE Configuration

[PE2] interface gigabitethernet2/0/0
[PE2- GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[PE2- GigabitEthernet2/0/0] ip address 11.1.1.2 255.255.255.0
Step 6 Configure the IS-IS route between CE1 and PE1.

# Configure CE1.
[CE1] isis 50
[CE1-isis-50] network-entity 50.0000.0000.0001.00
[CE1-isis-50] quit
[CE1] interface gigabitethernet1/0/0
[CE1-GigabitEthernet1/0/0] isis enable 50
[CE1-GigabitEthernet1/0/0] quit
[CE1] interface tunnel0/0/1
[CE1-Tunnel0/0/1] isis enable 50
[CE1-Tunnel0/0/1] quit
# 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
[PE1-Tunnel0/0/1] quit
Step 7 Configure the IS-IS route between CE2 and PE2.

# Configure CE2.
[CE2] isis 50
[CE2-isis-50] network-entity 50.0000.0000.0004.00
[CE2-isis-50] quit
# Configure PE2.
[PE2] isis 50 vpn-instance vpn1
[PE2-isis-50] network-entity 50.0000.0000.0003.00
[PE2-isis-50] quit
[PE2-GigabitEthernet2/0/0] isis enable 50
[PE2-GigabitEthernet2/0/0] quit
Step 8 Set up the MP-BGP peer relationship between PE1 and PE2.
# On PE1, specify PE2 as an IBGP peer, set up the IBGP connection by using the loopback
interface, and enable the capability of exchanging VPN IPv4 routing information between PE1
and PE2.
[PE1] bgp 100
[PE1-bgp] peer 3.3.3.9 as-number 100
[PE1-bgp] peer 3.3.3.9 connect-interface loopback 1
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 3.3.3.9 enable
[PE1-bgp-af-vpnv4] quit
# Enter the view of the BGP VPN instance vpn1 and import the direct routes and IS-IS routes.
Issue 02 (2012-03-30)

34

1 GRE Configuration
[PE1-bgp] ipv4-family vpn-instance vpn1

[PE1-bgp-vpn1] import-route direct
[PE1-bgp-vpn1] import-route isis 50
# On PE2, specify PE1 as an IBGP peer, set up the IBGP connection by using the loopback
interface, and enable the capability of exchanging VPN IPv4 routing information between PE2
and PE1.
[PE2] bgp 100
# Enter the view of the BGP VPN instance vpn1 and import the direct routes and IS-IS routes.
[PE2-bgp-vpn1] import-route isis 50
Step 9 Import BGP routes into IS-IS.

# Configure PE1.
[PE1] isis 50
[PE1-isis-50] import-route bgp
# Configure PE2.
[PE2] isis 50
[PE2-isis-50] import-route bgp

# After the configuration, CE1 and CE2 can successfully ping each other.
<CE1> ping 41.1.1.2
Reply from 41.1.1.2: bytes=56 Sequence=1 ttl=253 time=190 ms
0.00% packet loss
<CE2> ping 21.1.1.2
0.00% packet loss
----End
Configuration Files
l
Configuration file of CE1

#
Issue 02 (2012-03-30)

35

1 GRE Configuration
sysname CE1
#
isis 50
network-entity 50.0000.0000.0001.00
#
ip address 30.1.1.1 255.255.255.0
#
ip address 21.1.1.2 255.255.255.0
isis enable 50
#
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
Configuration 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
Configuration file of PE1

#
sysname PE1
#
ip vpn-instance vpn1
route-distinguisher 100:1
vpn-target 111:1 export-extcommunity
vpn-target 111:1 import-extcommunity
#
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
#
ip address 110.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
Issue 02 (2012-03-30)

36

1 GRE Configuration
ip address 1.1.1.9 255.255.255.255

#
ip binding vpn-instance vpn1
ip address 2.2.2.2 255.255.255.0
tunnel-protocol gre
source 50.1.1.2
isis enable 50
#
bgp 100
peer 3.3.3.9 as-number 100
peer 3.3.3.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpn1
import-route direct
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
#
isis 50 vpn-instance vpn1
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
Issue 02 (2012-03-30)

37

1 GRE Configuration

#
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 isis 50
#
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 41.1.1.2 255.255.255.0
isis enable 50
#
return
1.7.5 Example for Configuring the Keepalive Function for GRE

This section provides an example for configuring the Keepalive function of the GRE tunnel. In
this manner, the VPN does not select the GRE tunnel that cannot reach the remote end, and data
loss can be avoided.
As shown in Figure 1-9, Router A and Router B are configured with the GRE protocol. The two
ends of the GRE tunnel need be configured with the Keepalive function.
Figure 1-9 Networking diagram of configuring the Keepalive function on two ends of a GRE
tunnel
GE1/0/0
20.1.1.1/24
RouterA
Issue 02 (2012-03-30)
Internet
GE1/0/0
30.1.1.2/24
GRE Tunnel
Tunnel0/0/1
40.1.1.1/24
Tunnel0/0/1
40.1.1.2/24

RouterB
38

1 GRE Configuration
To enable the Keepalive function on one end of the GRE tunnel, run the keepalive command in
the tunnel interface view on the end.
TIP
If the Keepalive function is enabled on the source end, the forwarding function is obligatory, and the
Keepalive function is optional for the destination end.
Data Preparation
l
Data for configuring the routing protocol for the backbone network
Interval for sending Keepalive messages
Parameters of unreachable timer
Procedure
Step 1 Configure Router A and Router B to implement the interworking between the two devices.
The detailed procedures are not mentioned here.
Step 2 Configure a tunnel on Router A and enable the Keepalive function.
<RouterA> system-view
[RouterA] interface tunnel 0/0/1
[RouterA-Tunnel0/0/1] ip address 40.1.1.1 255.255.255.0
[RouterA-Tunnel0/0/1] keepalive period 20 retry-times 3
Step 3 Configure a tunnel on Router B and enable the Keepalive function.

<RouterB> system-view
[RouterB] interface tunnel 0/0/1
[RouterB-Tunnel0/0/1] ip address 40.1.1.2 255.255.255.0
[RouterB-Tunnel0/0/1] source 30.1.1.2
[RouterB-Tunnel0/0/1] destination 20.1.1.1
[RouterB-Tunnel0/0/1] keepalive period 20 retry-times 3
[RouterB-Tunnel0/0/1] quit

# The tunnel interface on Router A can successfully ping the tunnel interface on Router B.
<RouterA> ping -a 40.1.1.1 40.1.1.2
0.00% packet loss
ms
ms
ms
ms
ms
# Enable the debugging of the Keepalive messages on Router A and view information about the
Keepalive messages.
Issue 02 (2012-03-30)

39

1 GRE Configuration
<RouterA> terminal monitor

<RouterA> terminal debugging
<RouterA> debugging tunnel keepalive
May 18 2011 11:36:11.590.1+00:00 AR1220 TUNNEL/7/debug:GRE_KEEP:Judge keepalive
finished. Received keepalive detecting packet from peer router.
<RouterA>
May 18 2011 11:36:11.590.2+00:00 AR1220 TUNNEL/7/debug:GRE_KEEP_NSR: Mainboard u
lKeepaliveReceiveOpposite++ then send mbuf to slave when RECEIVE keepalive packe
t.
<RouterA>
May 18 2011 11:36:11.590.3+00:00 AR1220 TUNNEL/7/debug:GRE_FWD: Receive peer kee
palive on mainboard successfully. Put into decapsulation.
<RouterA>
May 18 2011 11:36:15.120.1+00:00 AR1220 TUNNEL/7/debug:GRE_KEEP:Judge keepalive
finished. Received keepalive response packet from peer router.
<RouterA>
May 18 2011 11:36:15.120.2+00:00 AR1220 TUNNEL/7/debug:GRE_FWD: Receive the resp
onse keepalive packet on mainboard successfully, keepalive finished.
<RouterA>
May 18 2011 11:36:15.120.3+00:00 AR1220 TUNNEL/7/debug:GRE_KEEP_NSR: Mainboard s
end mbuf to slaveboard when RECEIVE response packet.
----End
Configuration Files
l

#
sysname RouterA
#
ip address 20.1.1.1 255.255.255.0
#
ip address 40.1.1.1 255.255.255.0
tunnel-protocol gre
source 20.1.1.1
keepalive period 20
#
return

#
sysname RouterB
#
ip address 30.1.1.2 255.255.255.0
#
ip address 40.1.1.2 255.255.255.0
tunnel-protocol gre
source 30.1.1.2
keepalive period 20
#
return
Issue 02 (2012-03-30)

40

2 BGP MPLS IP VPN Configuration
BGP MPLS IP VPN Configuration
About This Chapter

This chapter describes the BGP/MPLS IP VPN configuration, including the introduction to the
BGP/MPLS IP VPN, common networking of the BGP/MPLS IP VPN, and configurations to
ensure the reliability of the BGP/MPLS IP VPN.
2.1 Introduction to BGP/MPLS IP VPN
This section describes the concepts and roles of the PE, P, and CE.
2.2 BGP/MPLS IP VPN Features Supported by the AR3200
The AR3200 supports basic and typical networking of the BGP/MPLS IP VPN, and such features
as reliability and QoS of the BGP/MPLS IP VPN.
2.3 Configuring a VPN Instance Enabled with the IPv4 Address Family
A VPN instance isolates VPN routes from public network routes. Configuring a VPN instance
enabled with the IPv4 address family allows a PE to advertise IPv4 routes and forward data.
2.4 Configuring Basic BGP/MPLS IP VPN
The basic BGP/MPLS IP VPN refers to a VPN that is established on one SP's MPLS backbone
network that does not span multiple ASs. The role of each PE, P, or CE of the basic BGP/MPLS
IP VPN is unique. For example, a router cannot function as both a PE and a CE.
2.5 Configuring Hub and Spoke
In the Hub and Spoke networking, an access control device is specified in the VPN, and users
communicate with each other through the access control device.
2.6 Configuring Inter-AS VPN Option A
In inter-AS VPN OptionA, an ASBR takes the peer ASBR as its CE and advertises VPNv4 routes
to the peer ASBR through EBGP.
2.7 Configuring Inter-AS VPN Option B
In inter-AS VPN Option B through MP-EBGP, two ASBRs receive VPNv4 routes from PEs in
their respective ASs and exchange the VPNv4 routes with each other.
2.8 Configuring Inter-AS VPN Option C (Solution 1)
EBGP connections in multi-hop mode are established between PEs of different ASs to exchange
VPNv4 routes.
Issue 02 (2012-03-30)

41

After LDP LSPs are established for the labeled BGP routes of the public network, EBGP
connections in multi-hop mode are established between PEs of different ASs to exchange VPNv4
routes.
2.10 Configuring HoVPN
HoVPN indicates a hierarchical VPN in which multiple PEs play different roles and form a
hierarchical structure. With this structure, these PEs function as one PE, and the performance
requirements for the PEs are lowered.
2.11 Configuring a Multi-VPN-Instance CE
By using OSPF multi-instance on CEs, you can implement service isolation on the LAN.
2.12 Connecting VPN and the Internet
Generally, users within a VPN can communicate only with each other, but 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.
2.13 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.
2.14 Configuring Route Reflection to Optimize the VPN Access Layer
If a PE and the connected CEs are in the same AS, you can deploy a BGP route RR to reduce
the number of IBGP connections between CEs and facilitate maintenance and management.
2.15 Maintaining BGP/MPLS IP VPN
This section describes how to maintain the BGP/MPLS IP VPN, which involves L3VPN traffic
checking, network connectivity monitoring, BGP connection resetting.
This section provides several configuration examples of VPN networking. In each configuration
example, the networking requirements, configuration roadmap, configuration notes,
configuration procedures, and configuration files are described.
Issue 02 (2012-03-30)

42

2.1 Introduction to BGP/MPLS IP VPN

This section describes the concepts and roles of the PE, P, and CE.
BGP/MPLS IP VPN is a PE-based L3VPN technology used in the Provider Provisioned VPN
(PPVPN) solution. BGP/MPLS IP VPN uses BGP to advertise VPN routes and MPLS to forward
VPN packets on the provider's backbone network.
Characterized by flexible networking modes, excellent extensibility, and convenient support for
MPLS QoS, BGP/MPLS IP VPN is widely used.
Figure 2-1 shows the networking diagram of BGP/MPLS IP VPN.
Figure 2-1 BGP/MPLS IP VPN model
VPN 1
Site
CE
CE
Service provider's
P backbone
P
VPN 2
Site
PE
PE
PE
VPN 2
Site
CE
CE
VPN 1
Site
The BGP/MPLS IP VPN model consists of the following parts:

l
A Customer Edge (CE) is an edge device on the customer network, which has one or more
interfaces directly connected to the service provider network. A CE can be a router, a
switch or a host. Usually, CEs cannot "sense" the existence of the VPN, and do not need
to support MPLS.
A Provider Edge (PE) is an edge device on the provider network, which is directly connected
to the CE. In the MPLS network, PEs perform all the VPN-related processing.
A Provider (P) is a backbone device on the provider network, which is not directly
connected to the CE. Ps only need to possess basic MPLS forwarding capabilities and do
not need to maintain information about VPNs.
2.2 BGP/MPLS IP VPN Features Supported by the AR3200

The AR3200 supports basic and typical networking of the BGP/MPLS IP VPN, and such features
as reliability and QoS of the BGP/MPLS IP VPN.
Issue 02 (2012-03-30)

43

Basic Networking
The AR3200 uses the Multi-protocol Extensions for Border Gateway Protocol (MP-BGP) to
achieve the VPN route exchange between PEs. The static route, Routing Information Protocol
(RIP) multi-instance, Open Shortest Path First (OSPF) multi-instance, Intermediate System-toIntermediate System (IS-IS) multi-instance, or external BGP (EBGP) can be used to exchange
routes between a PE and a CE. In addition, by using VPN targets to control the transmission of
VPN routes, the AR3200 can implement multiple VPN networking topologies including
Intranet, Extranet, and Hub and Spoke.
Generally, LSPs tunnels are used on the VPN backbone network. In some cases where PEs
support MPLS functions but P routers support only IP functions, GRE tunnels can be used.
Typical Networking
The AR3200 supports the following typical VPN networking scheme:
l
Inter-AS VPN
If a VPN backbone network spans multiple ASs, the inter-AS VPN must be configured.
The inter-AS VPN can be classified as Option A, Option B, or Option C.
Hierarchy of VPN(HoVPN)
To relieve the stress on a PE, the Hierarchy of VPN (HoVPN) can be configured. A device
on the convergence layer or the access layer is selected as the Underlayer Provider Edge
(UPE), which works jointly with the PE, that is, the Superstratum Provider Edge (SPE) on
the backbone layer, to implement the functions of the PE.
Multi-VPN-Instance CE
The Multi-VPN-Instance CE can be configured to improve the routing capability of the
LAN, solve the security problem of the LAN at a low cost, and ensure that the LAN services
are safely differentiated. Currently, LAN services can be differentiated by utilizing VLAN
switches, but they have a weak routing capability.
VPN and Internet interworking

The AR3200 supports the interworking between VPNs and the Internet. This section
describes how to implement this interworking by means of configuring static routes and
Policy-based Routing (PBC) on PEs.
Reliability
To improve the reliability of a VPN, the following networking modes are generally adopted.
l
The backbone network is an MPLS network, on which the devices adopt hierarchical
backup and are fully connected through high-speed interfaces. If there are many PEs on
the network, the BGP route reflector is deployed to reflect IPv4 VPN routes in order to
decrease the number of Multi-Protocol internal BGP (MP IBGP) connections.
Either a mesh topology or a ring topology is used at the convergence layer based on the
requirements.
2.3 Configuring a VPN Instance Enabled with the IPv4

Address Family
A VPN instance isolates VPN routes from public network routes. Configuring a VPN instance
enabled with the IPv4 address family allows a PE to advertise IPv4 routes and forward data.
Issue 02 (2012-03-30)

44


Before configuring a VPN instance enabled with an IPv4 address family, familiarize yourself
with the applicable environment, complete the pre-configuration tasks, and obtain the data
required for the configuration. This will help you complete the configuration task quickly and
accurately.
In BGP/MPLS IP VPN, each VPN is instantiated, and the instances of private forwarding
information of each VPN are established, that is, a VPN instance is established. A VPN instance
is also called the VPN Routing and Forwarding (VRF) table. In RFC 4364 (BGP/MPLS IP
VPNs), a VPN instance is called the per-site forwarding table.
The VPN instance is used to separate the VPN routes from public routes. In all the BGP/MPLS
IP VPN networking scenarios, configure VPN instances.
The VPN instance IPv4 address family can realize the separation of address spaces based on the
Router Distinguisher (RD), and can control VPN membership and routing rules based on the
VPN target attribute.
In addition, to achieve enhanced routing control, you can also enforce inbound and outbound
routing policies. The inbound routing policy is used to filter the routes imported into the VPN
instance IPv4 address family, and the outbound routing policy is used to filter the routes
advertised to other PEs.
Before configuring a VPN instance enabled with an IPv4 address family, complete the following
tasks:
l
Configuring routing policies if import or export routing policies need to be applied to the
VPN instance IPv4 address family
Configuring tunnel policies if load balancing is required, or the default selecting sequence
of Label Switched Paths (LSPs), Multiprotocol Label Switching Traffic Engineering
(MPLS TE) tunnels, or Generic Routing Encapsulation (GRE) tunnels need to be changed.
Data Preparation
To configure a VPN instance enabled with an IPv4 address family, you need the following data.
Issue 02 (2012-03-30)
No.
Data
Name of the VPN instance
(Optional) Description of the VPN instance
RD, VPN target attribute of the VPN instance IPv4 address families
(Optional) Maximum number of routes allowed by the VPN instance IPv4 address
families
(Optional) Routing policy that controls the receiving and sending of VPN routes
45

No.
Data
(Optional) Tunnel policy
2.3.2 Creating a VPN Instance

Configuring a VPN instance is the preliminary step for configuring other VPN attributes. After
a VPN instance is configured, a VPN routing and forwarding table is created.
Context
Perform the following steps on the PE that is connected to the CE.
Procedure
Step 1 Run:
system-view

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

NOTE
The VPN instance name is case sensitive. For example, vpn1 and VPN1 are considered different VPN
instances.
No default VPN instance exists on a PE, and multiple VPN instances can be created on the PE.
description description-information
The description of the VPN instance is configured.

The description of a VPN instance functions the same as the description of a host name or an
interface. It is recommended that the proper description be configured.
service-id service-id
A service ID is set for the VPN instance.

A service ID identifies a specific VPN instance and is unique on the same device.
----End
2.3.3 Configuring Attributes for the VPN Instance IPv4 Address

Family
To facilitate the management for routes of the VPN instance IPv4 address family, configure
other VPN attributes, such as the VPN target, route limit, and routing policy.
Issue 02 (2012-03-30)

46

Context
Perform the following steps on the PE that is configured with VPN instances.
NOTE
It is recommended to perform either Step 6 or Step 7.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The VPN instance view is displayed.

Step 3 Run:
ipv4-family
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
An RD is configured for the VPN instance IPv4 address family.

The VPN instance IPv4 address family takes effect only after an RD is configured for it. The
RDs configured in different VPN instance IPv4 address family views of the same PE must be
different.
NOTE
A configured RD cannot be changed or deleted. Delete a VPN instance or disable the VPN instance IPv4
address family before changing or deleting the RD of the VPN instance IPv4 address family.
Step 5 Run:
vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-extcommunity ]
The VPN target extended community attribute for the VPN instance is created.
The VPN target is the extended community attribute of the Border Gateway Protocol (BGP). It
controls the import and export of VPN routes. You can configure a maximum of 8 VPN targets
with a command.
routing-table limit number { alert-percent | simply-alert }
The maximum number of routes of the VPN instance is configured.

You can define the maximum number of routes for a VPN instance to prevent the PE from
importing too many routes from the CE.
Issue 02 (2012-03-30)

47

NOTE
If the routing-table limit command is run, the system gives a prompt when the number of routes injected
into the routing table of the VPN instance IPv4 address family exceeds the maximum. If the routing-table
limit command is run to increase the maximum number of routes supported in a VPN instance IPv4 address
family or the undo routing-table limit command is run to remove the limit on the routing table, for excess
routes, the following operations are required:
l For the excessive static routes, reconfigure them manually.
l For the excessive routes learned from CEs through the IGP multi-instance routing protocol, re-initiate
the multi-instance process of the routing protocol on the PE.
For the remote cross routes learned through the MP-IBGP and the BGP routes learned from CEs, the system
automatically refreshes them.

prefix limit number { alert-percent [ route-unchanged ] | simply-alert }
The maximum number of prefixes for the VPN instance IPv4 address family is configured.
You can define the maximum number of prefixes for a VPN instance IPv4 address family to
avoid importing too many prefixes from the CE.
limit-log-interval interval
The frequency of displaying logs when the number of routes exceeds the threshold is configured.
import route-policy policy-name
The inbound routing policy of the VPN instance IPv4 address family is configured.
export route-policy policy-name
The outbound routing policy of the VPN instance IPv4 address family is configured.
----End
2.3.4 (Optional) Configuring MPLS Label Allocation Based on the

VPN Instance IPv4 Address Family
This section describes how the MPLS label is allocated in a VPN instance IPv4 address
family. Specifically, it covers how the local PE allocates the same MPLS label for all routes of
the VPN instance IPv4 address family. If there are a large number of VPN routes, you can reduce
the number of MPLS labels maintained by PEs.
Context
Perform the following steps on the PE configured with VPN instances IPv4 address family.
Procedure
Step 1 Run:
system-view

Issue 02 (2012-03-30)

48

Step 2 Run:
The VPN instance view is displayed.

Step 3 Run:
ipv4-family
Step 4 Run:
apply-label per-instance
The MPLS label is allocated based on the VPN instance IPv4 address family, which ensures that
all the routes in a VPN instance IPv4 address family use the same MPLS label.
Generally, MPLS label allocation is in one label per route mode. When the number of routes
becomes larger, more labels are required.
Therefore, MPLS label allocation based on the VPN instance IPv4 address family is introduced
and provided by the AR3200. In this manner, all the routes of a VPN instance share the same
MPLS label.
----End

After configuring a VPN instance enabled with IPv4 address family , you can view information
about it on the local device, including RD attributes and other attributes.
Prerequisites
The functions of the VPN instance enabled with IPv4 address family are fully configured.
Procedure
l
Run the display ip vpn-instance verbose vpn-instance-name command to check detailed

information about the VPN instance, including information about the IPv4 address
family.
Run the display ip vpn-instance vpn-instance-name command to check brief information

about the VPN instance.
Run the display ip vpn-instance import-vt ivt-value command to check information about
all VPN instances with the specified import VPN-target attribute.
----End
Example
Run the display ip vpn-instance command. If brief information about the VPN instance is
displayed, it means that the configuration succeeded. For example:
<Huawei> display ip vpn-instance
Total VPN-Instances configured : 4
VPN-Instance Name
Address-family
vrf1
ipv4
vrf2
vrf3
ipv4
vrf4
ipv4
Issue 02 (2012-03-30)

49

Run the display ip vpn-instance verbose command. If detailed information about the VPN
instance is displayed, it means the configuration succeeded. For example:
<Huawei> display ip vpn-instance verbose
VPN-Instance Name and ID : vpn1, 1
Description : vrf1
Service ID : 123
Address family ipv4
Create date : 2010/03/05 16:26:27
Up time : 0 days, 00 hours, 09 minutes and 12 seconds
Route Distinguisher : 100:1
Export VPN Targets : 1:1
Import VPN Targets : 1:1
Label Policy : label per instance
Per-Instance Label : 1029
Import Route Policy : rp1
Export Route Policy : rp2
Tunnel Policy : tp1
Maximum Routes Limit : 200
Threshold Routes Limit : 10%
Prefix Routes Limit : 200
Threshold Prefixes Limit : 20%
Install Mode : route-unchanged
Log Interval : 30
Run the display ip vpn-instance import-vt ivt-value command. If information about all VPN
instances with the specified import VPN-target attribute is displayed, it means that the
configuration succeeded.
<Huawei> display ip vpn-instance import-vt 1:1
The number of ipv4-family matched the import-vt : 3
VPN-Instance Name and ID : vrf1, 1
2.4 Configuring Basic BGP/MPLS IP VPN

The basic BGP/MPLS IP VPN refers to a VPN that is established on one SP's MPLS backbone
network that does not span multiple ASs. The role of each PE, P, or CE of the basic BGP/MPLS
IP VPN is unique. For example, a router cannot function as both a PE and a CE.

Before configuring the basic BGP/MPLS IP VPN, familiarize yourself with the applicable
This section describes the basic BGP/MPLS IP VPN networking. Specifically, networking
features only one carrier and one intra-AS MPLS backbone network. In addition, the roles of
the P, PE, and CE are unique. For example, no device serves both as the PE and CE.
For special BGP/MPLS IP VPN networkings, such as HoVPN, and inter-AS VPN, additional
configurations are needed. You can refer to the related sections in this chapter for details.
In terms of the configuration of the BGP/MPLS IP VPN, it is critical for you to configure the
management of the advertisement of VPN routes on the MPLS backbone networks, including
the management of route advertisement between between PEs, and the PE and CE.
Issue 02 (2012-03-30)

50

You can configure MP-IBGP to exchange routes between PEs. To exchange routes between the
PE and CE, you can configure static routes, RIP multi-instance, OSPF multi-instance, IS-IS
multi-instance, or BGP based on the specific networking situations.
NOTE
If a VPN is used to receive the external routes and the routes advertised by non-PE devices, and advertise
these routes to PEs, the VPN is called a transit VPN.
If a VPN is used to accept the internal routes and the routes advertised by PEs, the VPN is called a stub
VPN. In most cases, the static route is only used to exchange routes between the PE and CE in the stub
VPN.
Before configuring basic BGP/MPLS IP VPN, complete the following tasks:
l
Configuring IGP for the MPLS backbone network (PE, P) to implement IP connectivity
Configuring basic MPLS functions and MPLS LDP for the MPLS backbone network (PE,
P)
Configuring tunnels between PEs based on the tunnel policy
Configuring the IP address for the CE interface that is connected to the PE
Data Preparation
To configure basic BGP/MPLS IP VPN, you need the following data.
No.
Data
Data for configuring a VPN instance:

l Name of the VPN instance
l (Optional) Description of the VPN instance
l RD, VPN target attribute of the VPN instance IPv4 address families
l (Optional) Routing policy used to control the sending and receiving of VPN routes
l (Optional) Tunnel policy
l (Optional) Maximum number of routes permitted in a VPN instance IPv4 address
family
IP address of the PE interface that is connected to the CE
Route-exchanging mode between the PE and CE, which can be the static route, RIP,
OSPF, IS-IS, or BGP
AS number of the PE
IP address and interface of the PE used to establish the BGP peer relationship
2.4.2 Configuring a VPN Instance

This section describes how to configure a VPN instance to manage VPN routes.
Issue 02 (2012-03-30)

51

Procedure
Step 1 For the details, see Configuring VPN Instances.
----End
2.4.3 Binding an Interface with a VPN Instance

After associating an interface with a VPN instance, you can change the interface to a VPN
interface. As a result, packets that pass through the interface are forwarded based on the
forwarding information of the VPN instance, and Layer 3 attributes are deleted. These Layer 3
attributes, such as the IP address and routing protocol that are configured for the interface, need
to be re-configured if required.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
interface interface-type interface-number
The view of the interface that is to be bound with the VPN instance is displayed.
Step 3 Run:
The interface is bound to the VPN instance.

NOTE
The running of the ip binding vpn-instance command on an interface can delete the Layer 3 attributes,
such as the IP address and routing protocol. If these Layer 3 attributes are still required, configure them
again.
An interface cannot be bound to a VPN instance that is not enabled with an address family.
Disabling an address family of a VPN instance deletes the Layer 3 attributes, such as the IP address and
routing protocol of the interface bound to the VPN instance. Disabling all the address families of a VPN
instance unbinds all the bound interfaces from the VPN instance.
Step 4 Run:
ip address ip-address { mask | mask-length }
The IP address is configured.

----End
2.4.4 (Optional) Configuring a Router ID for a BGP VPN Instance

IPv4 Address Family
You can configure different router IDs for BGP VPN instance IPv4 address families on the same
device.
Issue 02 (2012-03-30)

52

Context
By default, no router ID is configured for a BGP VPN instance IPv4 address family, and the
BGP router ID is used. This makes different BGP VPN instance IPv4 address families on the
same device have the same router ID. In some cases, different router IDs need to be configured
for different BGP VPN instance IPv4 address families. For example, BGP peer relationships
need to be established between different BGP VPN instance IPv4 address families on the same
PE.
There are two methods to configure a router ID for a BGP VPN instance IPv4 address family.
Procedure
l
Configuring router IDs for all BGP VPN instance IPv4 address families
1.
Run:
system-view

2.
Run:
bgp as-number
The BGP view is displayed.

3.
Run:
router-id vpn-instance auto-select
Automatic router ID selection is configured for all BGP VPN instance IPv4 address
families.
NOTE
Rules for automatically selecting a router ID for a BGP VPN instance IPv4 address family are
as follows:
l If the loopback interfaces configured with IP addresses are bound to the VPN instance
enabled with the IPv4 address family, the largest IP address among the IP addresses of the
loopback interfaces is selected as the router ID.
l If no loopback interfaces configured with IP addresses are bound to the VPN instance
enabled with the IPv4 address family, the largest IP address among the IP addresses of
other interfaces bound to the VPN instance is selected as the router ID, regardless of whether
the interface is Up or Down.
Configuring a router ID for a specified BGP VPN instance IPv4 address family
1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:
ipv4-family vpn-instance vpn-instance-name
The BGP-VPN instance IPv4 address family view is displayed.

4.
Run:
router-id { ipv4-address | auto-select }
Issue 02 (2012-03-30)

53

A router ID or automatic route ID selection is configured for the current BGP VPN
instance IPv4 address family.
----End
2.4.5 Configuring MP-IBGP Between PEs

By importing extended community attributes to BGP, MP-IBGP can advertise VPNv4 routes
between PEs.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
peer ipv4-address as-number as-number
The remote PE is specified as the peer.

Step 4 Run:
peer ipv4-address connect-interface loopback interface-number
The interface used to set up the TCP connection is specified.

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.
Step 5 Run:
ipv4-family vpnv4
The BGP VPNv4 sub-address family view is displayed.

Step 6 Run:
peer ipv4-address enable
The VPN IPv4 routing information can be exchanged between the peers.
----End
2.4.6 Configuring a Routing Protocol Between a PE and a CE

The routing protocol between a PE and a CE can be EBGP, IBGP, static route, RIP, OSPF, or
IS-IS. You can choose any of them as required in the configuration process.
Issue 02 (2012-03-30)

54

Context
Select one of the following configurations as required:
l
Configuring EBGP between a PE and a CE
Configuring IBGP between a PE and a CE
Configuring the static route between a PE and a CE
Configuring RIP between a PE and a CE
Configuring OSPF between a PE and a CE
Configuring IS-IS between a PE and a CE
Configure EBGP between s PE and a CE.
Procedure
Perform the following steps on the PE:
1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:
The BGP VPN instance IPv4 address family view is displayed.

4.
(Optional) Run:
as-number as-number
An AS number for the VPN instance IPv4 address family is specified.

During network transfer or service identification, a device needs to be simulated as
multiple BGP devices logically. In this case, you can run the as-number command
to configure an AS number for each VPN instance IPv4 address family.
NOTE
The AS number configured in the BGP-VPN instance IPv4 address family view cannot be the
same as the AS number configured in the BGP view.
5.
Run:
The CE is specified as the peer of the VPN.

6.
(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 the peer ebgpmax-hop command to ensure that the TCP connection can be set up between the EBGP
peers through multiple hops.
Issue 02 (2012-03-30)

55

7.
(Optional) When the direct route of the local CE needs to be imported to the VPN
routing table (for being advertised to the remote PE), you can choose either of the
following configurations:
Run the import-route direct [ med med | route-policy route-policy-name ]*
command to import the direct routes of the local CE into the VPN routing table.
Run the network ipv4-address [ mask | mask-length ] [ route-policy route-policyname ] command to import a specific direct route of the local CE into the VPN
routing table.
NOTE
The PE can automatically learn the direct route destined for the local CE, and the learned
direct route has a higher priority than the direct route that is advertised by the local CE
based on EBGP. Therefore, if this step is not configured, the PE cannot advertise the direct
route to the remote PE based on MP-BGP.
8.
(Optional) Run:
peer { group-name | ipv4-address } soo site-of-origin
The Site of Origin (SoO) attribute is configured for the specified CE.
When multiple CEs in a VPN site access different PEs, VPN routes sent from CEs to
PEs may return to this VPN site after traveling through the backbone network. This
may cause routing loops in the VPN site.
After the SoO attribute is configured on a PE, the PE adds the SoO attribute to the
route sent from a CE and advertises the route to other PE peers. Before advertising
the VPN route to the connected CE, the PE peers check the SoO attribute carried in
the VPN route. If the PE peers find that this SoO attribute is the same as the locally
configured SoO attribute, the PE peers do not advertise this VPN route to the connected
CE.
9.
(Optional) Run:
peer ip-address allow-as-loop [ number ]
The loop is allowed.

This step is optional and used in the Hub and Spoke networking.
Generally, BGP uses the AS number to detect a loop. In the Hub and Spoke
networking, however, if EBGP runs between the PE and CE at the Hub site, the HubPE carries the local AS number when advertising routes to the Hub-CE. Therefore,
the PE denies the subsequent routing update from the Hub-CE. To ensure the correct
transmission of routes in the Hub and Spoke networking, configure all the BGP peers
along the path, used for the Hub-CE to advertise private network routes to the SpokeCE and to accept the routes with the AS number repeated once.
10. (Optional) Run:
peer ip-address substitute-as
The AS number substitution is enabled for BGP.

This step is used for the networking scenario in which physically-dispersed CEs use
the same AS number. The configuration is performed on the PE.
Issue 02 (2012-03-30)

56

CAUTION
In the case of multi-homed CE, the BGP AS substitution function may lead to route
loops.
Perform the following steps on the CE:
1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:
The PE is specified as the peer of the VPN.

4.
(Optional) Run:

Generally, one or multiple directly-connected physical link(s) exist between a pair of
EBGP peers. If not, use the peer ebgp-max-hop command to ensure that the TCP
connection can be set up between the EBGP peers through multiple hops.
5.
Run:
import-route { direct | static | rip process-id | ospf process-id | isis
process-id } [ med med | route-policy route-policy-name ]*
Routes of the local site are imported.

The CE must advertise the reachable VPN segment addresses to the attached PE.
Through the PE, the addresses are advertised to the remote CEs. In applications, the
types of routes to be imported may be different.
l
Configure IBGP between a PE and a CE.

Perform the following steps on the PE:
1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:

4.
(Optional) Run:
as-number as-number
Issue 02 (2012-03-30)

57

An AS number for the VPN instance IPv4 address family is specified.

During network transfer or service identification, a device needs to be simulated as
multiple BGP devices logically. In this case, you can run the as-number command
to configure an AS number for each VPN instance IPv4 address family.
NOTE
The AS number configured in the BGP-VPN instance IPv4 address family view cannot be the
same as the AS number configured in the BGP view.
5.
Run:
The CE is specified as the peer of the VPN.

6.
(Optional) When the direct route of the local CE needs to be imported to the VPN
routing table (for being advertised to the remote PE), select either of the following
configurations:
Run the import-route direct [ med med | route-policy route-policy-name ]*
command to import the direct routes of the local CE to the VPN routing table..
Run the network ipv4-address [ mask | mask-length ] [ route-policy route-policyname ] command to import a specific direct route of the local CE to the VPN routing
table.
NOTE
The PE can automatically learn the direct route to the local CE. The route has a higher priority
than the direct route that is advertised by IBGP. Therefore, if this step is not performed, the PE
does not advertise the direct route to the remote PE using MP-BGP.
Perform the following steps on the CE:

1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:
The PE is specified as the IBGP peer.

4.
Run:
import-route { direct | static | rip process-id | ospf process-id | isis
process-id } [ med med | route-policy route-policy-name ]*
The route is imported to the local CE.

The CE advertises its VPN network segment to the connected PE, and the PE then
advertises the address to the remote CE. Note that the type of the imported route may
vary with different networking modes.
l
Configure the static route between a PE and a CE.

Perform the following steps on the PE. The CE is configured with the static route. The
configurations are common, therefore not mentioned here.
Issue 02 (2012-03-30)

58

NOTE
For details, see the chapter "IP Static Route Configuration" in the Huawei AR3200 Series Enterprise
Routers Configuration Guide - IP Routing.
1.
Run:
system-view

2.
Run:
ip route-static vpn-instance vpn-source-name destination-address { mask
| mask-length } interface-type interface-number [ nexthop-address ]
[ preference preference | tag tag ] *
The static route is configured for the specified VPN instance IPv4 address family.
3.
Run:
bgp as-number

4.
Run:

5.
Run:
import-route static [ med med | route-policy route-policy-name ]*
The configured static route is imported into the routing table of the BGP VPN
l
Configure RIP between a PE and a CE

Perform the following steps on the PE. The CE is configured with RIPv1 or RIPv2. The
configurations are common, therefore not mentioned here.
NOTE
For details, see Huawei AR3200 Series Enterprise Routers Configuration Guide - IP Routing.
1.
Run:
system-view

2.
Run:
rip process-id vpn-instance vpn-instance-name
The RIP instance is created between the PE and the CE and the RIP view is displayed.
A RIP process belongs to only one VPN instance. If you run a RIP process without
binding it to a VPN instance, this process is considered as a public network process.
A RIP process that belongs to a public network cannot be bound with a VPN instance.
3.
Run:
network network-address
The RIP is configured on the network segment of the interface bound with the VPN
instance.
4.
Run:
import-route bgp [ cost { cost | transparent } | route-policy route-policyname ]*
The BGP route is imported.

Issue 02 (2012-03-30)

59

After the import-route bgp command is run in the RIP view, the PE imports the VPNIPv4 routes learned from the remote PE into the RIP, and advertises them to its CE.
5.
Run:
quit
Return to the system view.

6.
Run:
bgp as-number

7.
Run:

8.
Run:
import-route rip process-id [ med med | route-policy route-policy-name ]*
The RIP route is imported into the routing table of the BGP VPN instance IPv4 address
family.
After the configuration of the import-route rip command in the BGP VPN view, the
PE imports the VPN routes learned from its CE into BGP, forms them into VPN-IPv4
routes, and advertises them to the remote PE.
NOTE
After a VPN instance is deleted or the IPv4 address family of the VPN instance is disabled, all
the associated RIP processes are deleted.
Configure OSPF between a PE and a CE

Perform the following steps on the PE. The CE is configured with OSPF. The configurations
are common, therefore not mentioned here.
NOTE
1.
Run:
system-view

2.
Run:
ospf process-id [ router-id router-id ] vpn-instance vpn-instance-name
The OSPF instance is created between the PE and the CE, and the OSPF view is
displayed.
An OSPF process belongs to only one VPN instance. If you run an OSPF process
without binding it to a VPN instance, this process is considered as a public network
process. An OSPF process that belongs to a public network cannot be bound with a
VPN instance.
The OSPF processes that are bound to the VPN instance do not use the public network
Router ID configured in the system view. Specify the router ID when starting an OSPF
process. Otherwise, based on the router ID selecting rule, the IP address of any
interface that is bound to the VPN instance is selected as the router ID in the OSPF
process.
3.
Issue 02 (2012-03-30)
(Optional) Run:
60

domain-id domain-id [ secondary ]
The domain ID is configured.

The domain ID can be expressed by an integer or in dotted decimal notation.
You can configure two domain IDs for each OSPF process. The domain IDs of
different processes are independent of each other.
There is no limitation to configure the domain IDs of the OSPF processes in different
VPNs on the PE. However, all the OSPF processes in one VPN should be configured
with the same domain ID to ensure correct routing advertisement.
The domain ID of an OSPF process is contained in the routes generated by this process.
When the OSPF routes are imported into BGP, the domain ID is added into the BGP
VPN route and is transmitted as the BGP extended community attribute.
By default, the domain ID is 0.
4.
(Optional) Run:
route-tag tag
The VPN route tag is configured.

By default, OSPF automatically allocates the VPN route tag based on the algorithm:
If the BGP process is not started on the local device, the tag value is 0 by default.
If the BGP process is started on the local device, the first two bytes of the tag value
are fixed as 0xD000, and the last two bytes are the local AS number by default.
That is, the tag value equals 3489660928 plus the local AS number.
5.
Run:
import-route bgp [ cost cost | route-policy route-policy-name | tag tag |
type type ] *

6.
Run:
area area-id
The OSPF area view is displayed.

7.
Run:
network ip-address wildcard-mask
OSPF is run on the network segment where the interface bound to the VPN instance
resides.
A network segment can belong to only one area. Therefore, specify to which area each
OSPF interface belongs.
OSPF can run on an interface if the following conditions are true:
The mask length of the IP address on the interface must be equal to or longer than
the wildcard-mask specified in the network command.
The primary IP address of the interface must be located in the network segment
specified in the network command.
For a loopback interface, OSPF advertises the IP address of the loopback interface as
a 32-bit host route by default, which bears no relation to the mask length configured
on the interface.
Issue 02 (2012-03-30)

61

8.
Run:
quit
Return to the OSPF view.

9.
Run:
quit

10. Run:
bgp as-number

11. Run:

12. Run:
import-route ospf process-id [ med med | route-policy route-policy-name ]*
The OSPF route is imported into the routing table of the BGP VPN instance IPv4
address family.
NOTE
After a VPN instance is deleted or the IPv4 address family of the VPN instance is disabled, all
related OSPF processes are deleted.
Configuring IS-IS between the PE and CE

Perform the following steps on the PE. The CE is configured with IS-IS. The configurations
are common, therefore not mentioned here.
NOTE
1.
Run:
system-view

2.
Run:
isis process-id vpn-instance vpn-instance-name
The IS-IS instance between the CE and the PE is created and the IS-IS view is
displayed.
An IS-IS process belongs to only one VPN instance. If you run an IS-IS process
without binding it to a VPN instance, this process is considered as a public network
process. An IS-IS process that belongs to a public network cannot be bound with a
VPN instance.
3.
Run:
network-entity net
The Network Entity Title (NET) is configured.

An NET defines the address of the current IS-IS area and the system ID of the
router. A maximum of three NETs can be configured for one process on a router.
4.
(Optional) Run:
is-level { level-1 | level-1-2 | level-2 }
Issue 02 (2012-03-30)

62

The level of the router is configured.

By default, the level of a router is Level-1-2.
5.
Run:
import-route bgp [ cost-type { external | internal } | cost cost | tag
tag | route-policy route-policy-name | [ level-1 | level-2 | level-1-2 ] ]
*

6.
Run:
quit

7.
Run:
The view of the interface bound to the VPN instance is displayed.

8.
Run:
isis enable [ process-id ]
IS-IS is enabled on the interface.

9.
Run:
quit

10. Run:
bgp as-number

11. Run:

12. Run:
import-route isis process-id [ med med | route-policy route-policy-name ]*
The IS-IS route is imported into the routing table of the BGP VPN instance IPv4
address family.
NOTE
After the VPN instance is deleted or the IPv4 address family of the VPN instance is disabled,
all IS-IS processes are deleted.
----End

After configuring the basic BGP/MPLS IP VPN function, you can view IPv4 VPN information
about the local and remote sites on the PE or the CE.
Prerequisites
The basic BGP/MPLS IP VPN function configurations are complete.
Issue 02 (2012-03-30)

63

Procedure
l
Run the display ip routing-table vpn-instance vpn-instance-name command to check

routing information about the specified VPN instance IPv4 address family on the PE.
Run the display ip routing-table command to check routing information on the CE.
Run the display ip vpn-instance [ vpn-instance-name ] interface command to check

information about the interface to which a specific VPN instance is bound.
----End
Example
Run the display ip routing-table vpn-instance vpn-instance-name command. If the VPN routes
related to the CE are displayed, it means the configuration succeeded.
Run the display ip routing-table command. If the routes to the peer CE are displayed on the
CE, it means the configuration succeeded.
Run the display ip vpn-instance [ vpn-instance-name ] interface command on the PE. If the
interface bound to a VPN instance is displayed, it means that the configuration succeeded.
2.5 Configuring Hub and Spoke

In the Hub and Spoke networking, an access control device is specified in the VPN, and users

Before configuring Hub and Spoke networking, familiarize yourself with the applicable
If all the users are required to access to a central access control device, the Hub and Spoke
networking is adopted. In the Hub and Spoke network, all the Spoke stations communicate
through the Hub station.
Pre-configuration Task
Before configuring Hub and Spoke, complete the following tasks:
l
Configuring IGP on PE devices and P devices in the MPLS backbone network
Configuring basic MPLS capability on PE devices and P devices in the MPLS backbone
network
Configuring the IP addresses, through which the CE devices access the PE devices, on the
CE devices
Data Preparation
Before configuring Hub and Spoke, you need the following data.
Issue 02 (2012-03-30)

64

No.
Data
Data for configuring a VPN instance:

l (Optional) Routing policy
l (Optional) Maximum number of routes permitted in the VPN instance IPv4
address families
l (Optional) Maximum number of route prefixes permitted in the VPN instance
IPv4 address family
l (Optional) The interval for logging the event that the number of routes exceeds
the threshold permitted in the VPN instance IPv4 address family
2
IP addresses through which the CE devices access the PE devices
Data for route configuration (static route, RIP, OSPF, IS-IS, or EBGP) between HubPE and Hub-CE, and Spoke-PE and Spoke-CE
2.5.2 Creating a VPN Instance

This section describes how to configure a VPN instance to manage VPN routes.
Context
Configure the VPN instance on each Spoke-PE and Hub-PE.
Every Spoke-PE is configured with a VPN instance, while each Hub-PE is configured with the
following two VPN instances:
l
VPN-in: receives and maintains all the VPNv4 routes advertised by all the Spoke-PEs.
VPN-out: maintains the routes of all the Hub stations and Spoke stations and advertises
those routes to all the Spoke-PEs.
NOTE
l Different VPN instances on a device have different names, RDs, and description.
l Performing either Step 6 or Step 7 is recommended.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The VPN instance is created and the VPN instance view is displayed.
Issue 02 (2012-03-30)

65

The name of the VPN instance is case sensitive. For example, vpn1 and VPN1 are considered
different VPN instances.
description description-information
The description about the VPN instance is configured.

The description can be used to record the relationship between a VPN instance and a VPN.
Step 4 Run:
ipv4-family
The IPv4 address family is enabled for the VPN instance, and the VPN instance IPv4 address
Step 5 Run:
The RD of the VPN instance is configured.

A VPN instance takes effect only after the RD is configured. Before configuring the RD,
configure only the description about the VPN instance.
The label is allocated based on VPN instance IPv4 address family. That is, all the routes in a
VPN instance IPv4 address family use the same label.
The MPLS labels are generally allocated in the "one label per route" manner.
The AR3200 provides the MPLS label allocation feature based on the VPN instance IPv4 address
family. That is, all the routes of a VPN instance IPv4 address family share the same label.
The maximum number of routes of the VPN instance IPv4 address family is configured.
You can define the maximum number of routes for a VPN instance IPv4 address family to avoid
importing excessive routes.
NOTE
If the routing-table limit command is run, the system gives a prompt when the number of routes injected
into the routing table of the VPN instance IPv4 address family exceeds the upper limit. If the routing-table
limit command is run to increase the maximum number of routes supported in a VPN instance IPv4 address
family or the undo routing-table limit command is run to remove the limit on the routing table, for excess
routes, the following operations are required:
l For the excessive static routes, reconfigure them manually.
l For the excessive routes learned from CEs through the IGP multi-instance routing protocol, re-initiate
the multi-instance process of the routing protocol on the PE.
l For the remote cross routes learned through the MP-IBGP and the BGP routes learned from CEs, the
system automatically refreshes them.

The maximum number of prefixes of the VPN instance IPv4 address family is configured.
Issue 02 (2012-03-30)

66

You can define the maximum number of prefixes for a VPN instance IPv4 address family to
avoid importing excessive prefixes.
----End
2.5.3 Configuring Route Attributes of the VPN Instance

This section describes how to configure the VPN target to control route advertisement and
acceptance.
Procedure
l
Configuring Hub-PE
1.
Run:
system-view

2.
Run:
ip vpn-instance vpn-instance-name1
The VPN instance view of the VPN-in is displayed.

3.
Run:
ipv4-family
The VPN instance IPv4 address family view is displayed.

4.
Run:
vpn-target vpn-target1 &<1-8> import-extcommunity
The VPN target extended community for the VPN instance IPv4 address family is
created to import the IPv4 routes advertised by all the Spoke-PEs.
vpn-target1 lists the Export VPN targets advertised by all the Spoke-PEs.
5.
(Optional) Run:
The import routing policy of the VPN instance IPv4 address family is configured.
6.
(Optional) Run:
The export routing policy of the VPN instance IPv4 address family is configured.
7.
Run:
quit

8.
Run:
The VPN instance view of the VPN-out is displayed.

9.
Run:
ipv4-family
Issue 02 (2012-03-30)

67


10. Run:
vpn-target vpn-target2 &<1-8> export-extcommunity
created to advertise the routes of all the Hubs and Spokes.
vpn-target2 lists the Import VPN targets advertised by all the Spoke-PEs.
11. (Optional) Run:
12. (Optional) Run:
l
Configuring Spoke-PE
1.
Run:
system-view

2.
Run:
The VPN instance view of the VPN-in is displayed.

3.
Run:
ipv4-family

4.
Run:
vpn-target vpn-target2 &<1-8> import-extcommunity
created to import the IPv4 routes advertised by all the Hub-PEs.
vpn-target2 should be included in the export VPN target list of the Hub-PE.
5.
Run:
vpn-target vpn-target1 &<1-8> export-extcommunity
created to advertise the IPv4 routes of the stations that the Spoke-PE accesses.
vpn-target1 should be included in the import VPN target list of the Hub-PE.
6.
(Optional) Run:
7.
(Optional) Run:
----End
Issue 02 (2012-03-30)

68

2.5.4 Binding an Interface with the VPN Instance

After associating an interface with a VPN instance, you can change the interface to a VPN
interface. As a result, packets that pass through the interface are forwarded based on the
forwarding information of the VPN instance, and such Layer 3 attributes as IP address and
routing protocol that are configured for the interface are deleted. These Layer 3 attributes need
to be re-configured if required.
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.
Perform the following steps on the Hub-PE and all the Spoke-PEs.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The view of the interface that is to be bound with the VPN instance is displayed.
Step 3 Run:
The interface is bound with the VPN instance.

NOTE
Running the ip binding vpn-instance command on an interface can delete the Layer 3 attributes, such as
the IP address and routing protocol. If these Layer 3 attributes are still required, configure them again.
An interface cannot be bound to a VPN instance that is not enabled with an address family.
Disabling an address family of a VPN instance deletes the Layer 3 attributes, such as the IP address and
routing protocol of the interface bound to the VPN instance. Disabling all the address families of a VPN
instance unbinds all the bound interfaces from the VPN instance.
Step 4 Run:

----End
2.5.5 Configuring MP-IBGP Between Hub-PE and Spoke-PE

between PEs.
Context
The Hub-PE must set up the MP-IBGP peer with all the Spoke-PEs. Spoke-PEs do not need to
set up the MP-IBGP peer between each other.
Issue 02 (2012-03-30)

69

Perform the following steps on the Hub-PE and Spoke-PE.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
The remote PE is specified as the peer.

Step 4 Run:
The interface to set up the TCP connection is specified.

NOTE
Step 5 Run:
ipv4-family vpnv4 [ unicast ]
The BGP VPNv4 address family view is displayed.

Step 6 Run:
The VPN IPv4 routing information is exchanged between the peers.

----End
2.5.6 Configuring Route Exchange Between PE and CE

The routing protocol between a PE and a CE can be EBGP, static route, or IGP. You can choose
any of them as required in the configuration process.
Context
The Hub-PE and the Hub-CE can exchange routes in the following ways.
Procedure
l
Configuring EBGP between the Hub-PE and Hub-CE

In this way, EBGP, IGP, or static routes can be adopted between the Spoke-PE and the
Spoke-CE.
To set up the EBGP peer between the Hub-PE and the Hub-CE and between the Spoke-PE
and Spoke-CE, perform the following steps on the Hub-PE:
Issue 02 (2012-03-30)

70

1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:

4.
Run:
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
Configuring IGP between the Hub-PE and Hub-CE

In this way, instead of BGP, IGP or static routes are adopted between the Spoke-PE and
the Spoke-CE. For details, refer to the chapter "BGP/MPLS IP VPN" in the Huawei AR3200
Series Enterprise Routers Feature Desripiton- VPN.
Configuring static routes between the Hub-PE and the Hub-CE

In this way, EBGP, IGP, or static routes can be adopted between the Spoke-PE and the
Spoke-CE.
If the Hub-CE uses the default route to access the Hub-PE, to advertise the default route to
all the Spoke-PEs, perform the following steps on the Hub-PE:
1.
Run:
system-view

2.
Run:
ip route-static vpn-instance vpn-source-name 0.0.0.0 0.0.0.0 nexthopaddress [ 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 interface bound with the VPNout.
3.
Run:
bgp as-number

4.
Run:
The BGP VPN instance IPv4 address family view is displayed. vpn-instance-name
refers to the VPN-out.
5.
Run:
network 0.0.0.0 0
Advertise the default route to all the Spoke-PEs through MP-BGP.

----End
Issue 02 (2012-03-30)

71

Follow-up Procedure
Choose one of the preceding methods as required. For detailed configurations, see Configuring
a Routing Protocol Between PE and CE.

After Hub and Spoke networking is configured, you can view VPN routing information on the
PE or CE.
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.
Run the display ip routing-table command to check routing information on the Hub-CE
and all the Spoke-CEs.
----End
Example
Run the preceding commands. 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.
Additionally, the Hub-CE and all the Spoke-CEs have routes to the Hub and all the Spoke
stations.
<Huawei> display ip routing-table
Total Number of Routes: 6
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
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?
<Huawei> display ip routing-table vpn-instance
-----------------------------------------------------------------------------Routing Tables: vpn1
Destinations : 3
Routes : 3
Destination/Mask
1.1.1.0/24
1.1.1.1/32
5.5.5.0/24
Issue 02 (2012-03-30)
Proto
Pre
Direct 0
Direct 0
Static 60
Cost
0
0
0
Flags NextHop
D
D
RD
1.1.1.1
127.0.0.1
1.1.1.2

Interface
Ethernet2/0/0
Ethernet2/0/0
Ethernet2/0/0
72

2.6 Configuring Inter-AS VPN Option A

In inter-AS VPN OptionA, an ASBR takes the peer ASBR as its CE and advertises VPNv4 routes
to the peer ASBR through EBGP.

Before configuring inter-AS VPN OptionA, familiarize yourself with the applicable
If the MPLS backbone network bearing the VPN routes is across multiple ASs, configure the
Inter-AS VPNs.
The Inter-AS VPN Option A is convenient to implement and is suitable when the amount of the
VPNs and the VPN routes on the PE is small.
In VPN-Option A, the Autonomous System Boundary Routers (ASBRs) must support the VPN
instances and can manage VPN routes. In addition, the ASBRs must reserve special interfaces
including sub-interfaces and physical interfaces for each inter-AS VPN. Option A, therefore,
requires high performance of the ASBRs. No inter-AS configuration is needed on the ASBRs.
Before configuring inter-AS VPN Option A, complete the following tasks:
l
Configuring IGP for MPLS backbone networks in each AS to keep IP connectivity of the
backbones in one AS
Enabling MPLS and MPLS LDP on the PE and the ASBR
Setting up the tunnel (LSP or GRE) between the PE and the ASBR in the same AS
Configuring the IP address of the CE interface through which the CE accesses the PE
Data Preparation
To configure inter-AS VPN Option A, you need the following data:
No.
Data
Data for configuring a VPN instance on the PE and ASBR:

l (Optional) Routing policy
l (Optional) Tunnel policy
address families
Issue 02 (2012-03-30)

73

No.
Data
IP address of the PE interface connected with the PE
AS number of the PE
IP addresses of the interfaces connected the ASBRs
Routing protocol configured between the PE and CE: static routes, RIP, OSPF, ISIS and BGP
IP addresses and interfaces setting up the IBGP peer between the PE and ASBR
2.6.2 Establishing Inter-AS VPN Option A

The VPN instance configured on a PE is used to access a CE, and the VPN instance configured
on an ASBR is used to access the peer ASBR.
Context
Inter-AS VPN Option A is easy to deploy. When the amount of the VPNs and the VPN routes
on the PE is small, this solution can be adopted.
Procedure
Step 1 Configuring Basic BGP/MPLS IP VPN on each AS
Step 2 Configuring ASBR by considering the peer ASBR as its CE
Step 3 Configuring VPN instances for the PE and the ASBR separately
The VPN instance for PE is used to access CE; that for ASBR is used to access its peer ASBR.
NOTE
In inter-AS VPN Option A mode, for the same VPN, the VPN targets of ASBR and the PE VPN instance
must be matched in an AS. This is not required for the PEs in different ASs.
----End

After configuring inter-AS VPN Option A, you can view information about all the BGP peer
relationships and IPv4 VPN routes on PEs or ASBRs.
Prerequisites
The configurations of the inter-AS VPN Option A function are complete.
Procedure
l
Issue 02 (2012-03-30)
Run the display bgp vpnv4 all peer command to check information about the BGP peers
on the PE or ASBR.
74

Run the display bgp vpnv4 all routing-table command to check the IPv4 VPN routes on
the PE or ASBR.

VPN routing table on the PE or ASBR.
----End
Example
After the successful configuration, run the display bgp vpnv4 all peer command on the PE or
ASBR, and you can view that the BGP VPNv4 peer relationship between the ASBR and PE in
the same AS is "Established".
<Huawei> display bgp vpnv4 all peer
BGP local router ID : 10.1.1.1
Local AS number : 100
Total number of peers : 1
Peer
PrefRcv
2.2.2.2
Peers in established state : 1
AS
MsgRcvd
MsgSent
100
OutQ
Up/Down
State
0 00:00:00 Established
Run the display bgp vpnv4all routing-table command on the PE or the ASBR, and you can
view the VPNv4 routes on ASBR.
<Huawei> display bgp vpnv4 all all routing-table
Total number of routes from all PE: 5
Route Distinguisher: 100:1
*>i
Network
NextHop
MED
10.1.1.0/24
1.1.1.9
LocPrf
100
PrefVal Path/Ogn
0
*>
*>
*
*>
Network
NextHop
10.2.1.0/24
192.1.1.0
192.1.1.2
0.0.0.0
192.1.1.2
0.0.0.0
192.1.1.1/32
MED
LocPrf
PrefVal Path/Ogn
0
0
0
0
0
0
0
200?
?
200?
?
VPN-Instance vpn1, router ID 2.2.2.9:

Network
NextHop
*>i
*>
*>
10.1.1.0/24
10.2.1.0/24
192.1.1.0
*>
192.1.1.1/32
1.1.1.9
192.1.1.2
0.0.0.0
192.1.1.2
0.0.0.0
MED
LocPrf
0
0
0
0
100
PrefVal Path/Ogn
0
0
0
0
0
?
200?
?
200?
?
Run the display ip routing-table vpn-instance command on the PE or ASBR, and you can view
all the relevant routes in the VPN routing table.
Issue 02 (2012-03-30)

75


Destinations : 3
Routes : 3
Destination/Mask
1.1.1.0/24
1.1.1.1/32
5.5.5.0/24
Proto
Pre
Direct 0
Direct 0
Static 60
Cost
0
0
0
Flags NextHop
D
D
RD
1.1.1.1
127.0.0.1
1.1.1.2
Interface
Ethernet2/0/0
Ethernet2/0/0
Ethernet2/0/0
2.7 Configuring Inter-AS VPN Option B

In inter-AS VPN Option B through MP-EBGP, two ASBRs receive VPNv4 routes from PEs in
their respective ASs and exchange the VPNv4 routes with each other.

Before configuring inter-AS VPN OptionB, familiarize yourself with the applicable
If the MPLS backbone network bearing VPN routes crosses multiple ASs, the inter-AS VPN is
needed.
If the ASBR can manage VPN routes, but there are not enough interfaces for each inter-AS VPN,
the inter-AS VPN Option B is adopted. In this option, the ASBR is involved in maintaining and
advertising VPN IPv4 routes.
Before configuring inter-AS VPN Option B, complete the following tasks:
l
Configuring IGP for MPLS backbone networks in each AS to realize IP connectivity of the
backbones in one AS
Configuring basic MPLS capability and MPLS LDP for the MPLS backbone network
Configuring VPN Instances on the PE devices connected with the CE devices and Binding
an Interface with a VPN Instance
Configuring the IP addresses of the CE interfaces through which the CE accesses the PE
Data Preparation
To configure inter-AS VPN Option B, you need the following data.
Issue 02 (2012-03-30)

76

No.
Data
Data for configuring a VPN instance on the PE:

l (Optional) Routing policy for controlling the import and export of VPN routes
address families
2
IP address of the PE interface connected with the PE
AS number of the PE
Routing policy configured between the PE and CE: static routes, RIP, OSPF, IS-IS
and BGP
2.7.2 Configuring MP-IBGP Between PEs and ASBRs in the Same

AS
between the PE and the ASBR.
Context
Perform the following steps on the PE and ASBR in the same AS.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
The peer ASBR is specified as the IBGP peer.

Step 4 Run:
The loopback interface is specified as the outgoing interface of the BGP session.
Issue 02 (2012-03-30)

77

NOTE
Step 5 Run:
The BGP-VPNv4 address family is displayed.

Step 6 Run:
The exchange of IPv4 VPN routes between the PE and ASBR in the same AS is enabled.
NOTE
In the AR3200, 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.
----End
2.7.3 Configuring MP-EBGP Between ASBRs in Different ASs

After the MP-EBGP peer relationship is established between ASBRs, either ASBR can advertise
the VPNv4 routes of its AS to the other ASBR.
Context
Perform the following steps on the ASBR.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The view of the interface connected with the ASBR interface is displayed.
Step 3 Run:
The interface IP address is configured.

Step 4 Run:
mpls
The MPLS capability is enabled.

Step 5 Run:
quit

Step 6 Run:
bgp as-number
Issue 02 (2012-03-30)

78


Step 7 Run:
The peer ASBR is specified as the EBGP peer.


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.
Step 9 Run:

Step 10 Run:
The exchange of IPv4 VPN routes with the peer ASBR is enabled.
----End
2.7.4 Controlling the Receiving and Sending of VPN Routes by

Using Routing Policies
An ASBR can either save all VPNv4 routes or partial VPNv4 routes (by filtering VPN targets
through a routing policy).
Context
The following describes two methods for controlling the receiving and sending of VPN routes:
l
Without VPN Target Filtering

Without the filtering method, the ASBR stores all the VPN IPv4 routes.
VPN Target Filtering

With the filtering method, the ASBR stores partial VPN IPv4 routes through routing
policies.
In practical applications, only one of the preceding methods is selected.
Procedure
l
Without VPN Target Filtering

Perform the following steps on the ASBR:
1.
Run:
system-view

2.
Issue 02 (2012-03-30)
Run:
79

bgp as-number

3.
Run:

4.
Run:
undo policy vpn-target
The VPN IPv4 routes are not filtered by the VPN target.
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 the Inter-AS VPN Option B mode, if the ASBR does not store information about
the VPN instance, the ASBR must save all the VPNv4 routing information and
advertise it to the peer ASBR. In this case, the ASBR should receive all the VPNv4
routing information without the VPN target filtering.
l
VPN Target Filtering

1.
Run:
system-view

2.
Run:
ip extcommunity-filter { basic-extcomm-filter-num | basic basic-extcommfilter-name | advanced-extcomm-filter-num | advanced advanced-extcommfilter-name } { permit | deny } { rt { as-number:nn | ipv4-address:nn } }
&<1-16>
The extended community filter is configured.

3.
Run:
route-policy route-policy-name permit node node
The routing policy is configured.

4.
Run:
if-match extcommunity-filter { { basic-extcomm-filter-num | advancedextcomm-filter-num } &<1-16> | advanced-extcomm-filter-name | basicextcomm-filter-name }
A matching rule based on the extended community filter is configured.

5.
Run:
quit

6.
Run:
bgp as-number

7.
Run:
Issue 02 (2012-03-30)

80


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
2.7.5 (Optional) Storing Information About the VPN Instance on

the ASBR
If VPNv4 routes need to be sent and received on an ASBR, you can configure the relevant VPN
instance on the ASBR.
Context
If the VPN receives and sends the VPNv4 routing information through the ASBR, configure the
corresponding instance on the ASBR. Otherwise, the instance is not needed.
Procedure
Step 1 Run:
system-view

Step 2 Run:
A VPN instance is created and the VPN instance view is displayed.

Step 3 Run:
ipv4-family
Step 4 Run:
The RD of the VPN instance IPv4 address family is configured.

Step 5 Run:
vpn-target vpn-target &<1-8> import-extcommunity
The VPN target extended community for the VPN instance IPv4 address family is created.
For the same VPN in the inter-AS VPN Option B mode, the VPN targets of the ASBR and PE
in an AS should match each other.
The VPN targets of the PE in different ASs must also match each other.
Issue 02 (2012-03-30)

81

The MPLS label is allocated based on the VPN instance IPv4 address family, which ensures that
all the routes in a VPN instance use the same MPLS label.
The maximum number of routes of the VPN instance IPv4 address family is configured.
The maximum number of prefixes of the VPN instance IPv4 address family is configured.
----End
2.7.6 (Optional) Enabling Next-Hop-based Label Allocation on the

ASBR
To save label resources on an ASBR, you can enable next-hop-based label allocation on the
ASBR. Note that next-hop-based label allocation and one label per instance need to be used
together on the ASBR.
Context
In a VPN Option B scenario, after next-hop-based label allocation is enabled on the ASBR, the
ASBR allocates only one label for the IPv4 VPN routes with the same next hop and outgoing
label. Compared with allocating a label for each IPv4 VPN route, next-hop-based label allocation
saves label resources.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Issue 02 (2012-03-30)

82

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.
CAUTION
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.
----End
2.7.7 Configuring the Routing Protocol Between CE and PE

The routing protocol between a PE and CE can be BGP, static route, or IGP. You can choose
any of them as required in the configuration process.
Procedure
Step 1 Choose one of the preceding methods as required. For detailed configurations, see 2.4.6
Configuring a Routing Protocol Between a PE and a CE.
----End

After configuring inter-AS VPN Option B, you can view information about all the BGP peer
relationships and VPNv4 routes on PEs or ASBRs.
Prerequisites
The configurations of the inter-AS VPN Option B function are complete.
Procedure
l
Run the display bgp vpnv4 all peer command to check the VPN IPv4 routing table on the
PE or ASBR.
Run the display bgp vpnv4 all routing-table command to check information about all the
BGP peers on the PE or ASBR.

Run the display mpls lsp command to check information about the LSP and label on the
ASBR.
----End
Issue 02 (2012-03-30)

83

Example
Run the display bgp vpnv4 all routing-table command on the ASBR. If the VPN IPv4 routes
are displayed, the configuration is successful.
<Huawei> display bgp vpnv4 all all routing-table
*>i
Network
NextHop
MED
10.1.1.0/24
1.1.1.9
LocPrf
100
PrefVal Path/Ogn
0
*>
*>
*
*>
Network
NextHop
10.2.1.0/24
192.1.1.0
192.1.1.2
0.0.0.0
192.1.1.2
0.0.0.0
192.1.1.1/32
MED
LocPrf
PrefVal Path/Ogn
0
0
0
0
0
0
0
200?
?
200?
?

Network
NextHop
*>i
*>
*>
10.1.1.0/24
10.2.1.0/24
192.1.1.0
*>
192.1.1.1/32
MED
1.1.1.9
192.1.1.2
0.0.0.0
192.1.1.2
0.0.0.0
LocPrf
100
0
0
0
PrefVal Path/Ogn
0
0
0
0
0
?
200?
?
200?
?
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.
Peer
PrefRcv
2.2.2.2
AS
MsgRcvd
MsgSent
100
OutQ
Up/Down
State
Run the display ip routing-table vpn-instance command on the PE. If the VPN routes are
displayed, the configuration is successful.
Destinations : 3
Routes : 3
Destination/Mask
1.1.1.0/24
Issue 02 (2012-03-30)
Proto
Pre
Direct 0
Cost
0
Flags NextHop
D
1.1.1.1

Interface
Ethernet2/0/0
84

1.1.1.1/32
5.5.5.0/24

Direct 0
Static 60
0
0
D
RD
127.0.0.1
1.1.1.2
Ethernet2/0/0
Ethernet2/0/0
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-hopbased label allocation, only one label is allocated for the VPN routes with the same next hop
and outgoing label.
<Huawei> display mpls lsp
------------------------------------------------------------------------------LSP Information: LDP LSP
------------------------------------------------------------------------------FEC
In/Out Label In/Out IF
Vrf Name
2.2.2.9/32
NULL/3
-/Pos1/0/0
2.2.2.9/32
1024/3
-/Pos1/0/0
3.3.3.9/32
NULL/3
-/Pos1/0/1
3.3.3.9/32
1025/3
-/Pos1/0/1

EBGP connections in multi-hop mode are established between PEs of different ASs to exchange
VPNv4 routes.

Before configuring inter-AS VPN OptionC, familiarize yourself with the applicable
If the MPLS backbone network bearing VPN routes crosses multiple ASs, the inter-AS VPN is
needed.
If each AS needs to exchange a large number of VPN routes, inter-AS VPN-Option C is a good
choice to prevent the ASBR from becoming a bottleneck that impedes network expansion. Two
solutions can be adopted to realize 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. A complete LSP
is set up as a result.
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 IGP to trigger the
establishment of an LDP LSP. This process can establish a complete LDP LSP between
the two PEs.
Solution 1 is described here, and solution 2 is described in 2.9 Configuring Inter-AS VPN
Option C (Solution 2).
Before configuring inter-AS VPN Option C, complete the following tasks:
Issue 02 (2012-03-30)

85

Configuring IGP for MPLS backbone networks in each AS to realize IP connectivity of the
backbones in one AS
Configuring basic MPLS capability and MPLS LDP for the MPLS backbone network
Configuring the IBGP peer relationship between the PE and ASBR in the same AS
Configuring a VPN Instance on the PE devices connected with the CE devices and Binding
an Interface with a VPN Instance
Configuring the IP addresses of the CE interfaces through which the CE accesses the PE
Data Preparation
To configure inter-AS VPN Option C, you need the following data:
No.
Data
Data for configuring a VPN instance on the PE and ASBR:

l Routing policy for controlling the import and export of VPN routes
address families
IP address of the PE interface connected with the CE
AS number of the PE
Routing policy configured on the ASBR
Routing protocol configured between the PE and CE: static routes, RIP, OSPF, ISIS, or BGP
NOTE
In inter-AS VPN-Option C, do not enable LDP between ASBRs.

If LDP is enabled on the interfaces between ASBRs, LDP sessions are then established between the ASBRs.
In this case, the ASBRs establish an egress LSP and send Mapping messages to the upstream ASBR. After
receiving Mapping messages, the upstream ASBR establishes a transit LSP. When there are high-volume
BGP routes, enabling LDP on the interfaces between ASBRs leads to the occupation of a large number of
LDP labels.
2.8.2 Enabling the Labeled IPv4 Route Exchange

In inter-AS VPN Option C, a BGP LSP needs to be established between ASs, and labeled IPv4
routes need to be exchanged between BGP peers.
Issue 02 (2012-03-30)

86

Procedure
l
Configuring the PE
1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:
peer ipv4-address label-route-capability
The exchange of the labeled IPv4 routes with the ASBR in the same AS is enabled.
l
Configuring the ASBR

1.
Run:
system-view

2.
Run:
The view of the interface connected with the peer ASBR is displayed.
3.
Run:
The interface IP address is configured.

4.
Run:
mpls
The MPLS capability is enabled.

5.
Run:
quit

6.
Run:
bgp as-number

7.
Run:
peer ipv4-address label-route-capability
The exchange of the labeled IPv4 routes with the PE of the same AS is enabled.
In the Option C solution, establish an inter-AS VPN LSP. The related PEs and ASBRs
exchange public network routes with the MPLS labels.
The ASBR establishes a common EBGP peer relationship with the remote ASBR to
switch labeled IPv4 routes.
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.
Issue 02 (2012-03-30)

87

By default, BGP peers cannot process labeled IPv4 routes.

8.
Run:
The peer ASBR is specified as the EBGP peer.

9.
(Optional) Run:

10. Run:
peer ipv4-address label-route-capability [ check-tunnel-reachable ]
The exchange of the labeled IPv4 routes with the peer ASBR is enabled.
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 MPEBGP peer relationship between PEs over a faulty LSP because this will cause
data forwarding failures.
If tunnel reachability checking is disabled, BGP advertises labeled routes to peers
whether the tunnels for imported routes are reachable or not.
----End
2.8.3 Configuring a Routing Policy to Control Label Distribution

Configure a routing policy to control label allocation for the inter-AS BGP LSP. If labeled IPv4
routes are advertised to the PE of the local AS, re-allocate MPLS labels to these routes. If routes
sent by the PE of the local AS are advertised to the peer ASBR, allocate MPLS labels to these
routes.
Procedure
l
Creating a routing policy

1.
Run:
system-view

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
Issue 02 (2012-03-30)

88

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.
7.
Run:
apply mpls-label
The label is allocated to the IPv4 route.

l
Applying routing policies

1.
Run:
system-view

2.
Run:
bgp as-number

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.
4.
Run:
peer ipv4-address route-policy policy-name2 export
The routing policy adopted when the route is advertised to the peer ASBR is created.
----End
2.8.4 Establishing the MP-EBGP Peer Relationship Between PEs

By importing extended community attributes to BGP, MP-EBGP can advertise VPNv4 routes
between PEs. PEs of different ASs are generally not directly connected. Therefore, to set up the
EBGP connection between the PEs of different ASs, configure the permitted maximum hops
between the PEs.
Procedure
l
Configuring ASBRs
The address of the loopback interface that is used to set up the BGP session is advertised
to the peer ASBR and to the PEs of the other ASs.
1.
Issue 02 (2012-03-30)
Run:
89

system-view

2.
Run:
bgp as-number

3.
Run:
network ip-address [ mask | mask-length ] [ route-policy route-policyname ]
The loopback address of the PE in the local AS is advertised to the remote ASBR.
l
Configuring PE
Perform the following steps on the PE that is connected to a CE:
1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:
The peer PE is specified as the EBGP peer.

4.
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.
5.
Run:
The BGP VPNv4 address family is displayed.

6.
Run:
The exchange of VPN IPv4 routes with the peer PE is enabled.

l
(Optional) Configuring route reflector (RR)

If the Route Reflector (RR) is used to advertise VPNv4 routes, perform the following steps
on the RR.
1.
Run:
system-view

2.
Run:
bgp as-number

Issue 02 (2012-03-30)

90

3.
Run:
The BGP VPNv4 address family is displayed.

4.
Run:
The exchange of VPN IPv4 routes with the peer RR is enabled.

5.
Run:
peer ipv4-address next-hop-invariable
The next hop is not changed when the route is advertised to the EBGP peer.
----End
2.8.5 Configuring the Route Exchange Between CE and PE

The routing protocol between a PE and a CE can be BGP, static route, or IGP.
Context
For detailed configurations, see Configuring a Routing Protocol Between PE and CE.

After configuring inter-AS VPN Option C, you can view information about all the BGP peer
relationships, VPNv4 routes on PEs or ASBRs, and labels of IPv4 routes on ASBRs.
Prerequisites
The configurations of the inter-AS VPN Option C function are complete.
Procedure
l
Run the display bgp vpnv4 all peer command to check the BGP peers on the PE.
Run the display bgp vpnv4 all routing-table command to check the VPN IPv4 routing
table on the PE or ASBR.
Run the display bgp routing-table label command to check information about the label
of the IPv4 route on the ASBR.

----End
Example
Run the display bgp vpnv4 all peer command on the PE. If the status of the EBGP peer between
PEs is "Established", the configuration is successful.
Run the display bgp vpnv4 all routing-table command. You can view that the PE has the VPN
IPv4 routes while the ASBR has no VPN IPv4 route.
Run the display bgp routing-table label command on the ASBR. If information about the label
of the IPv4 route is displayed, the configuration is successful.
Issue 02 (2012-03-30)

91

Run the display ip routing-table vpn-instance command on the PE. If the VPN routes to related
CEs are displayed, the configuration is successful.

After LDP LSPs are established for the labeled BGP routes of the public network, EBGP
connections in multi-hop mode are established between PEs of different ASs to exchange VPNv4
routes.

Before configuring inter-AS VPN OptionC, familiarize yourself with the applicable
If the MPLS backbone network bearing VPN routes spans multiple ASs, the inter-AS 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 ASBR from becoming a bottleneck that impedes network expansion. Two
solutions can be adopted to realize 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.
Solution 2: The IBGP peer relationship between the PE and the 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 IGP to trigger the
establishment of an LDP LSP. In this manner, a complete LDP LSP can be established
between the two PEs.
If an ASBR is ready to access a large number of PEs, Solution 2 is recommended because of the
easy configuration.
Before configuring inter-AS VPN-Option C, 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
Configuring the basic MPLS functions and MPLS LDP for the MPLS backbone network
of each AS
Configuring VPN instances on PEs that access CEs, and associating VPN instances with
PE interfaces that connect CEs
Configuring IP addresses on CE interfaces that access PEs
Configuring a name for the prefix list used to filter labeled BGP routes of the public network
Issue 02 (2012-03-30)

92

Data Preparation
To configure inter-AS VPN-Option C, you need the following data.
No.
Data
Data for configuring a VPN instance on a PE:

l VPN instance name
l (Optional) The routing policy that controls the sending and receiving of VPN
routing information
l (Optional) The maximum number of routes allowed by the VPN instance IPv4
address families
IP addresses of PE interfaces that access CEs
AS number of each AS
IP addresses of the interfaces between ASBRs
Routing policies on ASBRs
Route protocol between PEs and CEs
(Optional) The name of the IP prefix list used to filter the labeled BGP routes of
the public network
NOTE
In inter-AS VPN-Option C, do not enable LDP between ASBRs.

If LDP is enabled on the interfaces between ASBRs, LDP sessions are then established between the ASBRs.
In this case, the ASBRs establish an egress LSP and send Mapping messages to the upstream ASBR. After
receiving Mapping messages, the upstream ASBR establishes a transit LSP. When there are high-volume
BGP routes, enabling LDP on the interfaces between ASBRs leads to the occupation of a large number of
LDP labels.
2.9.2 Establishing the EBGP Peer Relationship Between ASBRs

The EBGP peer relationship is established between ASBRs to advertise routes destined for the
loopback interfaces on PEs.
Procedure
l
Perform the following steps on ASBRs:

1.
Run:
system-view

2.
Run:
The view of the interface that connects the remote ASBR is displayed.
Issue 02 (2012-03-30)

93

3.
Run:

4.
Run:
quit

5.
Run:
bgp as-number

6.
Run:
The remote ASBR is configured as the EBGP peer.

7.
(Optional) Run:

----End
2.9.3 Advertising the Routes of the PE in the Local AS to the Remote

PE
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 the PEs.
Procedure
l
Perform the following steps on an ASBR:
1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:
network ip-address [ mask | mask-length ]
4.
Run:
quit

Issue 02 (2012-03-30)

94

The BGP routes are imported to IGP.

Perform the following steps on the peer ASBR:
1.
Run:
system-view

2.
Run:
ospf process-id
The OSPF view is displayed.

3.
Run:
import-route bgp [ cost cost ] [ route-policy route-policy-name ]
The BGP routes are imported to IGP.

4.
Run:
quit

----End
2.9.4 Enabling the Capability of Exchanging Labeled IPv4 Routes

To establish an inter-AS BGP LSP, enable labeled IPv4 route exchange between ASBRs.
Procedure
l
Creating a routing policy.

1.
Run:
system-view

2.
Run:
route-policy route-policy-name permit node seq-number
The routing policy applied to advertise routes to the remote ASBR is configured.
3.
Run:
apply mpls-label
Labels for IPv4 routes are distributed.

4.
Run:
quit

l
Applying a Routing Policy

Perform the following steps on ASBRs.
1.
Run:
system-view

2.
Run:
bgp as-number
Issue 02 (2012-03-30)

95


3.
Run:
peer ipv4-address route-policy route-policy-name export
The routing policy applied to advertise routes to the remote ASBR is configured.
4.
Run:
quit

l
Enabling the function of labeled IPv4 route exchange.

1.
Run:
system-view

2.
Run:
The view of the interface connecting the remote ASBR is displayed.

3.
Run:
mpls
The MPLS function is enabled.

4.
Run:
quit

5.
Run:
bgp as-number

6.
Run:
peer ipv4-address label-route-capability [ check-tunnel-reachable ]
The labeled IPv4 route exchange capability with the remote ASBR is configured.
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 MPEBGP peer relationship between PEs over a faulty LSP because this will cause
data forwarding failures.
If tunnel reachability checking is disabled, BGP advertises labeled routes to peers
whether the tunnels for imported routes are reachable or not.
----End
2.9.5 Establishing an LDP LSP for the Labeled BGP Routes of the
Public Network
By enabling LDP on ASBRs to allocate labels for BGP, you can establish LDP LSPs for labeled
BGP routes of the public network that are filtered in the IP prefix list
Issue 02 (2012-03-30)

96

Procedure
l
An LDP LSP is established for the labeled BGP routes of the public network that is filtered
by the IP prefix list.
1.
Run:
system-view

2.
Run:
mpls
The MPLS view is displayed.

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
2.9.6 Establishing the MP-EBGP Peer Relationship Between PEs

By introducing extended community attributes to BGP, MP-IBGP can advertise VPNv4 routes
between PEs. PEs of different ASs are generally not directly connected. Therefore, to set up the
EBGP connection between the PEs of different ASs, configure the permitted maximum hops
between the PEs.
Procedure
l
Perform the following steps on PEs:

1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:
The remote PE is specified as the EBGP peer.

4.
Run:
peer ipv4-address connect-interface interface-type interface-number ipv4source-address
The source interface that sends BGP packets is specified.

5.
Run:
peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum number of hops permitted to establish the EBGP peer is specified.
6.
Run:
ipv4-family vpnv4
Issue 02 (2012-03-30)

97

The BGP VPNv4 sub-address family view is displayed.

7.
Run:
The VPNv4 route exchange capability with the remote PE is enabled.

----End
2.9.7 Configuring the Route Exchange Between a CE and a PE

The routing protocol between a PE and a CE can be BGP, static route, or IGP.
Procedure
l
Configuring a PE.
1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:

4.
Run:
The CE is configured to be the peer of the VPN private network.

5.
(Optional) Run:
The maximum number of hops in the EBGP connection is specified.

6.
(Optional) Run:
network ip-address mask
The direct routes are advertised to the local CE.

7.
(Optional) Run:
The routing loop is permitted.

8.
(Optional) Run:
peer ip-address substitute-as
The function of BGP AS number substitution is enabled.

l
Configuring a CE.
1.
Run:
system-view

2.
Run:
bgp as-number
Issue 02 (2012-03-30)

98


3.
Run:
peer ipv4-address as-number
The PE is configured as the peer.

4.
(Optional) Run:
The maximum number of hops in the EBGP connection is specified.

5.
Run:
import-route { direct | static | rip [ process-id ] | ospf process-id |
isis process-id } [ med med | route-policy route-policy-name ]*
Routes of the local site are imported.

----End

After configuring inter-AS VPN Option C (solution 2), you can view information about all the
BGP peer relationships, VPNv4 routes on PEs, and labels of IPv4 routes on ASBRs.
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.
Run the display bgp vpnv4 all routing-table command to check information about the
VPN-IPv4 routing table on a PE or an ASBR.
Run the display bgp routing-table label command to check information about the labels
of IPv4 routes on an ASBR.

VPN routing table on a PE.
Run the display mpls route-state [ vpn-instance vpn-instance-name ] [ { exclude |

include } { idle | ready | settingup } * | destination-address mask-length ] [ verbose ]
command to check the matching relationship between routes and the LSP on an ASBR.
Run the display ip routing-table command to check information about the routing table
on an ASBR.
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.
----End
Example
Run the display bgp vpnv4 all peer command. The command output shows that the EBGP peer
relationship between PEs is established.
Issue 02 (2012-03-30)

99

Run the display bgp vpnv4 all routing-table command on a PE and an ASBR. The command
output shows that BGP VPNv4 routes and BGP VPN instance routes are on the PE, but not on
the ASBR.
Run the display bgp routing-table label command on an ASBR. The command output shows
information about labels of IPv4 routes.
Run the display ip routing-table vpn-instance vpn-instance-name command on a PE. The
command output shows that the VPN routing table of the PE has the VPN routes to the CE related
to the specified VPN instance.
Run the display mpls route-state verbose command on an ASBR. The command output shows
the routes with the type as L, that is, the labeled BGP routes of the public network.
Run the display ip routing-table command on an ASBR. The command output shows 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.
[ASBR] display ip routing-table 4.4.4.9 verbose
-----------------------------------------------------------------------------Routing Table : Public
Summary Count : 1
Destination
: 4.4.4.9/32
Protocol
: EBGP
Preference
: 255
NextHop
: 192.1.1.2
State
: Active Adv
Tag
: 0
Label
: 15360
IndirectID: 0x0
RelayNextHop
: 0.0.0.0
TunnelID
: 0x6002006
Process ID
: 0
Cost
: 1
Neighbour: 192.1.1.2
Age
: 00h12m53s
Priority
: low
QoSInfo
: 0x0
Interface
Flags
: GE2/0/0
: D
Run the display mpls lsp command on an ASBR. The command output shows that an LDP LSP
is established between the ASBR and the remote PE. Additionally, the LDP ingress LSP to the
remote PE can be found on the local PE.
[ASBR] 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
: POPGO
Mpls-Mtu
: -----TimeStamp
: 15829sec
Bfd-State
: --BGPKey
: ---
Issue 02 (2012-03-30)

100

2.10 Configuring HoVPN

HoVPN indicates a hierarchical VPN in which multiple PEs play different roles and form a
hierarchical structure. With this structure, these PEs function as one PE, and the performance
requirements for the PEs are lowered.

Before configuring HoVPN, familiarize yourself with the applicable environment, complete the
pre-configuration tasks, and obtain the required data. This can help you complete the
configuration task quickly and accurately.
For hierarchical VPN networks, adopt the HoVPN to reduce the requirements for PE devices.
Before configuring HoVPN, complete the task of Configuring Basic BGP/MPLS IP VPN=.
Data Preparation
To configure HoVPN, you need the following data.
No.
Data
Relationship between the UPE and SPE
Name of the VPN instance sending default routes to the UPE
2.10.2 Specifying UPE

Before configuring a UPE, establish the VPNv4 peer relationship between the UPE and SPE.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
peer { ipv4-address | group-name } as-number as-number
The UPE is specified as the BGP peer of the SPE.

Issue 02 (2012-03-30)

101

Step 4 Run:
The BGP VPNv4 sub-address family is displayed.

Step 5 Run:
peer { ipv4-address | group-name } enable
The capability of exchanging BGP VPNv4 routing information with the peer is enabled.
Step 6 Run:
peer { ipv4-address | group-name } upe
The peer is specified as the UPE of the SPE.

----End
2.10.3 Advertising Default Routes of a VPN Instance

The SPE advertises the UPE of a default route with the next hop address as the local address.
This process enables the SPE to instruct VPN packet forwarding on the UPE.
Context
Perform the following steps on the SPE.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
ipv4-family vpnv4
The BGP-VPNv4 sub-address family view is displayed.

Step 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.
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 configuring HoVPN, the local CE has no route that is destined for the network segment
of the interface on the remote CE, but has a default route with the next hop as the UPE.
Issue 02 (2012-03-30)

102

Prerequisites
The configurations of the HoVPN function are complete
Procedure
l
----End
Example
Run the display ip routing-table on the CE connected with the UPE. The command output
shows that there is a default route whose next hop is the UPE and there is no route to the network
segment where the peer CE resides.
<CE> display ip routing-table
Destinations : 5
Routes : 5
Destination/Mask Proto Pre Cost
Flags NextHop
Interface
0.0.0.0/0 BGP
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
InLoopBack0GigabitEthernet1/0/0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
2.11 Configuring a Multi-VPN-Instance CE


Before configuring a multi-VPN-instance CE, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the data required for the
configuration. This will help you complete the configuration task quickly and accurately.
The multi-VPN-instance CE is used in the LAN. You can implement service isolation through
the multiple OSPF instances on the CE devices.
One OSPF process can belong to only one VPN instance but one VPN instance can run several
OSPF processes.
The Multi-VPN-Instance CE can be considered a networking solution that isolates services by
isolating routes. Before configuring a multi-VPN-instance CE, disable routing loop detection.
Before configuring a multi-VPN-instance CE, complete the following tasks:
l
Issue 02 (2012-03-30)
Configuring a VPN Instance on the multi-instance CE, and the PE that is accessed by it
(each service with a VPN instance)
103

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)
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
Data Preparation
To configure a multi-VPN-instance CE, you need the following data.
No.
Data
Names of the VPN instances corresponding with the OSPF processes used by each
service
OSPF process number and Router ID used by each service
Routes advertised by each OSPF process
2.11.2 Configuring the OSPF Multi-Instance on the PE

Different services are configured in different instances and use different OSPF process IDs.
Context
Perform the following steps on the PE that is accessed by the multi-instance CE.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The OSPF multi-instance is configured.

Different services have different OSPF process IDs. However, router IDs of different services
do not necessarily differ.
Step 3 Run:
area
area-id

Step 4 Run:
The IP address of the interface connected to the multi-instance CE is advertised.

Issue 02 (2012-03-30)

104

Step 5 Run:
quit
The OSPF view is displayed.

Step 6 Run:
import-route bgp

Step 7 Run:
quit

Step 8 Run:
bgp as-number

Step 9 Run:

Step 10 Run:
import-route ospf process-id
The OSPF multi-instance route is imported.

----End
2.11.3 Configuring the OSPF Multi-Instance on the Multi-Instance

CE
The process ID of the OSPF multi-instance configured on the multi-VPN-instance CE must be
the same as that configured on the PE.
Context
Perform the following steps on the multi-instance CE.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The OSPF multi-instance is configured.

The OSPF process ID corresponds to that of the PE.
Step 3 Run:
area area-id
Issue 02 (2012-03-30)

105


Step 4 Run:
The IP address of the interface connected the PE is advertised.

NOTE
If the multi-instance CE does not learn the routes of a LAN through the OSPF multi-instance of the process,
the routes of the LAN need to be imported to the OSPF instances of the process.
----End
2.11.4 Canceling the Loop Detection on the Multi-Instance CE

If the route loop check is performed, the CE discards the route from the PE with the DN bit being
1.
Context
Perform the following steps on the MCE.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The OSPF multi-instance view is displayed.

Step 3 Run:
vpn-instance-capability simple
Loop detection is not performed.

----End

After the multi-VPN-instance CE is configured, the VPN routing table of the CE contains the
routes destined for the LAN and remote sites for each service.
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.
----End
Issue 02 (2012-03-30)

106

Example
Run the display ip routing-table vpn-instance command on the multi-instance CE to check
the VPN routing table. If there are routes to the LAN and the remote nodes for each service, the
configuration is successful.
[MCE] display ip routing-table vpn-instance vpna
-----------------------------------------------------------------------------Routing Tables: vpna
Destinations : 8
Routes : 8
Flags NextHop
Interface
10.1.1.0/24 O_ASE 150 1
D 192.1.1.1
Pos1/0/0
10.1.1.1/32 O_ASE 150 1
D 192.1.1.1
Pos1/0/0
10.3.1.0/24 Direct 0
0
D 10.3.1.2
Pos3/0/0
10.3.1.1/32 Direct 0
0
D 10.3.1.1
Pos3/0/0
10.3.1.2/32 Direct 0
0
D 127.0.0.1
InLoopBack0Pos3/0/0
192.1.1.0/24 Direct 0
0
D 192.1.1.2
Pos1/0/0
192.1.1.1/32 Direct 0
0
D 192.1.1.1
Pos1/0/0
192.1.1.2/32 Direct 0
0
D 127.0.0.1
InLoopBack0Pos1/0/0
2.12 Connecting VPN and the Internet

Generally, users within a VPN can communicate only with each other, but 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.

Before configuring the interconnection between a VPN and the Internet, familiarize yourself
with the applicable environment, complete the pre-configuration tasks, and obtain the required
data. This can help you complete the configuration task quickly and accurately.
You can enable VPN users to access the Internet, by supplementing certain software
configurations in the established VPN network.
Before configuring VPN users to access the Internet, complete the following task:
l
Setting up the VPN network
Data Preparation
To configure interconnection between a VPN and the Internet, you need the following data.
Issue 02 (2012-03-30)
No.
Data
Names of the VPN instances
Destination IP address of static routes

107

2.12.2 Configuring the Static Route on the CE

This section describes how to configure static routes on CEs to forward packets from the VPN
to the Internet.
Context
Perform the following steps on the CE.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ip route-static ip-address { mask | mask-length } { interface-type interfacenumber [ nexthop-address ] | nexthop-address } [ preference preference | tag tag ]
* [ description text ]
The static route to the public network destination address.

ip-address can be the destination address of the public network or 0.0.0.0. If the dest-ipaddress is 0.0.0.0, the static route is also called the default route, the mask of which must be
0.0.0.0 or the mask-length of which must be 0. Note that, the out-interface must be the interface
connected directly with the PE, and the next-hop is the IP address of the peer PE interface
connected directly with the CE.
NOTE
If the CE and the PE are connected through an Ethernet network, the next-hop must be specified.
----End
2.12.3 Configuring the Private Network Static Route on the PE

This section describes how to configure static routes on PEs to forward packets from the VPN
to the Internet.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
ip route-static vpn-instance vpn-source-name destination-address { mask | masklength } nexthop-address public [ preference preference | tag tag ]* [ description
text ]
Issue 02 (2012-03-30)

108

The static route from the VPN to the Internet is configured and the next-hop address is a public
network address.
----End
2.12.4 Configuring the Static Route to VPN on the Device of the

Public Network
This section describes how to configure static routes to VPN users to forward packets from the
Internet to the VPN.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
ip route-static ip-address { mask | mask-length } { interface-type interfacenumber | 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 are connected through an Ethernet network, the next-hop must be specified.
----End

After configuring the interconnection between a VPN and the Internet, the VPN routing table
contains the routes destined for the CE and the router in the public network, and the routing table
in the destined device of the public network contains the route to the CE.
Prerequisites
The configurations of the VPN and the Internet function are complete.
Procedure
l

Run the display ip routing-table command to check the routing table on the CE and the
destination router in the public network.
----End
Issue 02 (2012-03-30)

109

Example
Run the display ip routing-table vpn-instance command on the PE. The command output
shows that the route to the CE and the route to the destination router in the public network exist
in the VPN routing table.
<Huawei> display ip routing-table vpn-instance vpn1
Destinations : 7
Routes : 7
Flags NextHop
Interface
0.0.0.0/0
Static 60
0
RD 100.1.1.2
Pos2/0/0
10.1.1.0/24 Direct 0
0
D 10.1.1.2
Pos1/0/0
10.1.1.1/32 Direct 0
0
D 10.1.1.1
Pos1/0/0
10.1.1.2/32 Direct 0
0
D 127.0.0.1
Pos2/0/0
10.2.1.0/24 BGP
255 0
RD 3.3.3.3
Pos2/0/0
10.2.1.1/32 BGP
255 0
RD 3.3.3.3
Pos2/0/0
10.2.1.2/32 BGP
255 0
RD 3.3.3.3
Pos2/0/0
100.3.1.1/32 BGP
255 0
D 10.1.1.1
Pos1/0/0
Run the display ip routing-table command on the CE. The command output shows that the CE
has the route to the destination router in the public network and the destination router in the
public network has the route to the CE.
<Huawei> display ip routing-table
Destinations : 10
Routes : 10
Flags NextHop
Interface
1.1.1.1/32 Direct 0
0
D 127.0.0.1
LoopBack1
2.2.2.2/32 OSPF
10
2
D 100.1.1.2
Pos2/0/0
3.3.3.3/32 OSPF
10
3
D 100.1.1.2
Pos2/0/0
100.1.1.0/24 Direct 0
0
D 100.1.1.1
Pos2/0/0
100.1.1.1/32 Direct 0
0
D 127.0.0.1
Pos1/0/0
100.1.1.2/32 Direct 0
0
D 100.1.1.2
Pos2/0/0
100.2.1.0/24 OSPF
10
2
D 100.1.1.2
Pos2/0/0
100.3.1.0/24 Static 60
0
D 10.1.1.1
Pos1/0/0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
Run the ping command to check the connectivity between the CE and the destination device on
the public network.
<Huawei> ping 100.3.1.1
0.00% packet loss
ms
ms
ms
ms
ms
2.13 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.
Issue 02 (2012-03-30)

110


Before configuring an RR to optimize the VPN backbone layer, familiarize yourself with the
applicable environment, complete the pre-configuration tasks, and obtain the required data. This
can help you complete the configuration task quickly and accurately.
The BGP speaker does not advertise the routes learned from IBGP devices to its IBGP peers.
To make a PE advertise the routes of the VPN that the PE accesses to the BGP VPNv4 peers in
the same AS, the PE must establish IBGP connections with all the peers to directly exchange
VPN routing information. That is, MP IBGP peers must establish full connections between each
other. Suppose there are n PEs (including ASBRs) in an AS, n (n-1)/2 MP IBGP connections
need to be established. A large number of IBGP peers consume a great amount of network
resources.
The Route Reflector (RR) can solve this problem. In an AS, one router can be configured as the
RR to reflect VPNv4 routes and the other PEs and ASBRs serve as the clients, which are called
Client PEs. An RR can be a P, PE, ASBR, or a router of other types.
The introduction of the RR reduces the number of MP IBGP connections. This lightens the
burden on PEs and 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 routers in the backbone network
Establishing tunnels (LSPs or GRE tunnels) between the RR and all Client PEs
Data Preparation
To configure the BGP VPNv4 route reflection, you need the following data.
No.
Data
Local AS number and peer AS number
Type and number of the interfaces used to set up the TCP connection
BGP peer group name and IP addresses of peers
2.13.2 Configuring the Client PEs to Establish MP IBGP

Connections with the RR
An MP-IBGP connection is configured between the PE and the RR to facilitate VPNv4 route
reflection.
Issue 02 (2012-03-30)

111

Context
Perform the following steps on all Client PEs.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
The RR is specified as the BGP peer.

Step 4 Run:
peer ipv4-address connect-interface interface-type interface-number
The interface is specified as an interface to establish the TCP connection.

The interface IP address must be the same as the MPLS LSR ID. It is recommended to specify
a loopback interface to establish the TCP connection.
Step 5 Run:
ipv4-family vpnv4

Step 6 Run:
peer
ipv4-address enable
The capability of exchanging VPNv4 routes between the PE and RR is enabled.

----End
2.13.3 Configuring the RR to Establish MP IBGP Connections with

the Client PEs
MP-IBGP connections are configured between the RR and all its clients (PEs) to facilitate
VPNv4 route reflection.
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

1.
Run:
system-view
Issue 02 (2012-03-30)

112


2.
Run:
bgp as-number

3.
Run:
group group-name [ internal ]
An IBGP peer group is created.

4.
Run:
peer group-name connect-interface interface-type interface-number
The interface is specified as an interface to establish the TCP connection. The interface
IP address must be the same as the MPLS LSR ID. It is recommended to specify a
loopback interface to establish the TCP connection.
5.
Run:
ipv4-family vpnv4

6.
Run:
peer group-name enable
The capability of exchanging IPv4 VPN routes between the RR and the peer group is
enabled.
7.
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

1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:
The client PE is specified as the BGP peer.

4.
Run:

The interface IP address must be the same as the MPLS LSR ID. It is recommended
to specify a loopback interface to establish the TCP connection.
5.
Run:
ipv4-family vpnv4

6.
Run:
Issue 02 (2012-03-30)

113

The capability of exchanging VPNv4 routes between the RR and the client PE is
enabled.
----End
2.13.4 Configuring Route Reflection for BGP IPv4 VPN routes

The premise of enabling BGP VPNv4 route reflection is that the RR has established the MPIBGP connections with all its clients (PEs).
Context
Perform the following steps on the RR.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
ipv4-family vpnv4

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:
The filtering of VPNv4 routes based on the VPN target is disabled.

rr-filter { extcomm-filter-number | extcomm-filter-name }
The reflection policy is configured for the RR.

Only IBGP routes of which the RT extended community attribute matches the reflection policy
can be reflected.
----End

After configuring an RR to optimize the VPN backbone layer, you can view BGP VPNv4 peer
information and VPNv4 routing information on the RR or its clients (PEs).
Issue 02 (2012-03-30)

114

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.
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.
Run the display bgp vpnv4 all group [ group-name ] command to check information about
the VPNv4 peer group on the RR.
----End
Example
If the configurations succeed,
l
The status of the MP IBGP connections between the RR and all Client PEs is "Established"
after running the display bgp vpnv4 all peer command on the RR or Client PEs.
Peer
V
AS MsgRcvd MsgSent
2.2.2.9
4
100 2
4
3.3.3.9
4
100 3
5
Peer of IPv4-family for vpn instance :
VPN-Instance vpna, router ID 1.1.1.9:
10.1.1.1
4 65410
79

OutQ Up/Down
State PrefRcv
0
00:00:31
Established 0
0
00:01:23
Established 0
82
0 01:13:29
Established
The RR and each Client PE can receive and send VPNv4 routing information between each
other after running the display bgp vpnv4 all routing-table peer command on the RR or
the Client PEs.
<Huawei> display bgp vpnv4 all routing-table peer 2.2.2.9 received-routes
*>i
Network
NextHop
MED
LocPrf
1.1.1.1
2.2.2.9
100
PrefVal Path/Ogn
0
If the peer group is configured, information about the group members is displayed and the
status of the BGP connections between the RR and the group members is "Established"
after running the display bgp vpnv4 all group command on the RR.
<Huawei> display bgp vpnv4 all group vpna
Group in VPNV4:
BGP peer-group: vpna
Remote AS: 100
Issue 02 (2012-03-30)

115

Authentication type configured: None

Type : internal
Configured hold timer value: 180
Keepalive timer value: 60
Connect-retry timer value: 32
Minimum route advertisement interval is 0 seconds
Connect-interface has been configured
PeerSession Members:
2.2.2.2
Peer Preferred Value: 0
No routing policy is configured
Peer Members:
Peer
V
AS MsgRcvd
PrefRcv
2.2.2.2
100
MsgSent
13
15
OutQ
Up/Down
State
2.14 Configuring Route Reflection to Optimize the VPN

Access Layer
If a PE and the connected CEs are in the same AS, you can deploy a BGP route RR to reduce
the number of IBGP connections between CEs and facilitate maintenance and management.

Before configuring an RR to optimize the VPN access layer, familiarize yourself with the
applicable environment, complete the pre-configuration tasks, and obtain the required data. This
can help you complete the configuration task quickly and accurately.
If a PE and multiple CEs accessing the PE are located in the same AS, to reduce the IBGP
connections between the CEs, the PE can be configured as an RR to reflect the routes of the
VPN instance, and the CEs can be configured as clients, which are called Client CEs. This
procedure simplifies and facilitates network maintenance and management.
Before configuring route reflection to optimize the VPN access layer, complete the following
tasks:
l
Configure a routing protocol for the MPLS backbone network to implement IP interworking
between the routers in the backbone network.
Data Preparation
Before configuring route reflection to optimize the VPN access layer, you need the following
data.
Issue 02 (2012-03-30)
No.
Data
Local AS number and peer AS number
Type and number of the interfaces used to set up the TCP connection
116

No.
Data
BGP peer group name and IP addresses of peers
2.14.2 Configuring All Client CEs to Establish IBGP Connections

with the RR
This section describes how to configure an IBGP connection between the client (a CE) and the
RR to reflect VPNv4 routes.
Context
Perform the following steps on all Client CEs.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:
The RR is specified as the BGP peer.

Step 4 Run:
peer ipv4-address connect-interface
interface-type interface-number

The interface IP address must be the same as the MPLS LSR ID. It is recommended to specify
a loopback interface to establish the TCP connection.
----End
2.14.3 Configuring the RR to Establish MP IBGP Connections with

All Client CEs
This section describes how to configure MP-IBGP connections between the RR and all its clients
(CEs) to reflect VPNv4 routes to all clients (CEs).
Context
Issue 02 (2012-03-30)

117

Procedure
l
Establishing the MP-IBGP Connection with the Peer Group

1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:

4.
Run:
group group-name [ internal ]
An IBGP peer group is created.

5.
Run:
peer group-name connect-interface interface-type interface-number

6.
Run:
peer ip-address
groupgroup-name
The peer is added to the peer group.

l
Establishing the MP-IBGP Connection with Each Peer

Perform Step 1 to Step 5 repeatedly on the RR to establish MP-IBGP connections with all
client CEs.
1.
Run:
system-view

2.
Run:
bgp as-number

3.
Run:

4.
Run:
The peer of the BGP IPv4 VPN instance is configured.

5.
Run:

----End
Issue 02 (2012-03-30)

118

2.14.4 Configuring Route Reflection for the Routes of the BGP VPN
Instance
The premise of enabling BGP VPNv4 route reflection is that the RR has established the MPIBGP connections with all its clients (CEs).
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
bgp as-number

Step 3 Run:

Step 4 Enable route reflection for the routes of the BGP VPN instance IPv4 address family on the RR.
l Run the peer group-name reflect-client command to enable route reflection if the RR
establishes the IBGP connection with the peer group consisting of all Client CEs.
l Run the peer ipv4-address reflect-client command repeatedly to enable route reflection if
the RR establishes the IBGP connection with each PE rather than the peer group.
reflect between-clients
Route reflection between the Client CEs is enabled.

By default, route reflection between the Client CEs is enabled.
If the Client CEs are fully connected, you can use the undo reflect between-clients command
to disable route reflection between the clients to reduce costs.
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
Issue 02 (2012-03-30)

119


After configuring an RR to optimize the VPN access layer, you can view information on the RR
about peers of the BGP VPN instance, routes received from the peers, and the VPNv4 routes
advertised to the peers.
Prerequisites
The configurations of the route reflection to optimize the VPN access layer function are
complete.
Procedure
l
Run the display bgp [ vpnv4 vpn-instance vpn-instance-name ] peer [ ipv4-address ]

verbose command to check information about the peer group of the BGP VPN instance on
the RR.
Run the display bgp peer [ ipv4-address ] verbose command to check information about
the BGP peer on the Client CE.
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.
Run the display bgp routing-table peer ipv4-address { advertised-routes | receivedroutes }command or display bgp routing-table statistics command to check information
about the routes received from the peer or the routes advertised to the peer on the Client
CE.
Run the display bgp vpnv4 vpn-instance vpn-instance-name group [ group-name ]

command to check information about the VPNv4 peer group on the RR.
Run the display bgp group [ group-name ] command to check information about the
VPNv4 peer group on the CE.
----End
Example
If the configurations succeed, you can achieve the following objects:
l
You can find that the status of the MP IBGP connections between the RR and all Client
CEs is "Established" after running the display bgp vpnv4 all peer command on the RR.
Peer
V
AS MsgRcvd MsgSent
2.2.2.9
4
100 2
4
3.3.3.9
4
100 3
5
10.1.1.1
4 65410
79

OutQ Up/Down
State PrefRcv
0
00:00:31
Established 0
0
00:01:23
Established 0
82
0 01:13:29
Established
You can find that the status of the IBGP connections between the RR and all Client CEs is
"Established" after running the display bgp peer command on the Client CE.
<Huawei> display bgp peer
BGP Local router ID : 1.2.3.4
local AS number : 10
Issue 02 (2012-03-30)

120


Peer
V
AS
PrefRcv
MsgRcvd

MsgSent OutQ Up/Down
State
1.1.1.1
100
1.2.5.6
200
32
35
0 00:00:07
Idle
0
You can view the routing information advertised by the RR to the Client CE or the routing
information advertised by the Client CE to the RR after running the display bgp vpnv4
all routing-table peer command on the RR.
<Huawei> display bgp vpnv4 all routing-table peer 2.2.2.9 received-routes
*>i
Network
NextHop
MED
LocPrf
1.1.1.1
2.2.2.9
100
PrefVal Path/Ogn
0
You can view the routing information advertised by the Client CE to the RR and the routing
information advertised by the RR to the Client CE after running the display bgp routingtable peer ipv4-address { advertised-routes | received-routes } command or display bgp
vpnv4 all routing-table statistics command on the Client CE.
<Huawei> display bgp routing-table peer 1.1.1.1 accepted-routes
Network
NextHop
MED
LocPrf
i 1.1.1.1/32
1.1.1.1
0
100
*>i 10.1.1.0/24
1.1.1.1
0
100
<Huawei> display bgp vpnv4 all routing-table statistics
PrefVal Path/Ogn
0
0
?
?

If the peer group is configured, 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" after running the display bgp vpnv4 all group command on the RR.
<Huawei> display bgp vpnv4 all group vpna
Group in VPNV4:
BGP peer-group: vpna
Remote AS: 100
Authentication type configured: None
Type : internal
Issue 02 (2012-03-30)

121

Configured hold timer value: 180

Keepalive timer value: 60
Connect-retry timer value: 32
Minimum route advertisement interval is 0 seconds
Connect-interface has been configured
PeerSession Members:
2.2.2.2
Peer Preferred Value: 0
No routing policy is configured
Peer Members:
Peer
V
AS MsgRcvd
PrefRcv
2.2.2.2
100
MsgSent
13
15
OutQ
Up/Down
State
2.15 Maintaining BGP/MPLS IP VPN

This section describes how to maintain the BGP/MPLS IP VPN, which involves L3VPN traffic
checking, network connectivity monitoring, BGP connection resetting.
2.15.1 Viewing the Integrated Route Statistics of All IPv4 VPN

Instances
Integrated route statistics of all VPN instances refer to the sum of statistics of all VPN instances.
Procedure
l
Run the display ip routing-table all-vpn-instance statistics command to check the

integrated route statistics of all VPN instances.
----End
2.15.2 Displaying BGP/MPLS IP VPN Information

This section describes how to monitor the running status of the BGP/MPLS IP VPN, which
involves VPN instance information checking, VPNv4 peer information checking, and BGP peer
log information checking.
Context
In routine maintenance, you can run the following commands in any view to check the status of
BGP/MPLS IP VPN.
Procedure
l

IP routing table of a VPN instance.
Run the display ip vpn-instance [ verbose ] [ vpn-instance-name ] command to check

information about the VPN instance.
Run the display bgp [ vpnv4 { all | vpn-instance vpn-instance-name } ] routing-table

label command to check information about labeled routes in the BGP routing table.
Issue 02 (2012-03-30)

122

Run the display bgp vpnv4 { all | route-distinguisher route-distinguisher | vpninstance vpn-instance-name } routing-table ipv4-address [ mask | mask-length ] command
to check information about the BGP VPNv4 routing table.
Run the display bgp vpnv4 { all | route-distinguisher route-distinguisher | vpninstance vpn-instance-name } routing-table statistics command to check statistics about
the BGP VPNv4 routing table.
Run the display bgp vpnv4 { all | route-distinguisher route-distinguisher | vpninstance vpn-instance-name } routing-table command to check information about the
BGP VPNv4 routing table.
Run the display bgp vpnv4 { all | vpn-instance vpn-instance-name } group [ groupname ] command to check information about the BGP VPNv4 peer group.
Run the display bgp vpnv4 { all | vpn-instance vpn-instance-name } peer [ [ ipv4address ] verbose ] command to check BGP VPNv4 peer information.
Run the display bgp vpnv4 { all | vpn-instance vpn-instance-name } network command
to check the routing information advertised by BGP VPNv4.
Run the display bgp vpnv4 { all | vpn-instance vpn-instance-name } paths [ as-regularexpression ] command to check the AS path information of BGP VPNv4.
Run the display bgp vpnv4 vpn-instance vpn-instance-name peer { group-name | ipv4address } log-info command to check the BGP peer's log information of a specified VPN
instance.
----End
2.15.3 Checking the Network Connectivity and Reachability

This section describes how to use the ping command to detect the network connectivity between
the source and the destination, and how to use the tracert command to check the devices through
which data packets are sent from the source to the destination.
Procedure
l
Run the ping [ ip ] [ -a source-ip-address | -c count | -d | -f | -h ttl-value | -i interfacetype interface-number | -m time | -n | -p pattern | -q | -r | -s packetsize | -t timeout | -tos tosvalue | -v | -vpn-instance vpn-instance-name ] * host command to check the network
connectivity.
Run the tracert [ -a source-ip-address | -f first-ttl | -m max-ttl | -p port | -q nqueries | -vpninstance vpn-instance-name | -w timeout ] * host command to trace the gateways that the
packet passes by from the source to the destination.
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 ] * vpn-instance vpn-name remote remoteaddress mask-length command to check the connectivity of the L3VPN LSP.
----End
Example
After the VPN configuration, run the ping command with vpn-instance vpn-instance-name on
the PE to check whether the PE and the CEs that belong to the same VPN can communicate with
each other. If the ping fails, you can use the tracert command with vpn-instance vpn-instancename to locate the fault.
<Huawei> ping -vpn-instance vpna 10.1.1.1
Issue 02 (2012-03-30)

123


0.00% packet loss
If multiple interfaces bound to the same VPN exist on the PE, specify the source IP address (a source-ip-address) when you ping or tracert the remote CE that accesses the peer PE.
Otherwise, the ping or tracert may fail.
If you do not specify a source IP address, the PE randomly chooses the smallest IP address of
the interface bound to the VPN on the PE as the source address of the ICMP packet. If no route
to the selected address exists on the CE, the ICMP packet sent back from the peer PE is discarded.
<Huawei> ping -a 202.38.160.243 -c 8 10.1.1.2
0.00% packet loss
ms
ms
ms
ms
ms
ms
ms
ms
2.15.4 Resetting BGP Statistics of a VPN Instance IPv4 Address

Family
BGP statistics of the VPN instance IPv4 address family cannot be restored after being cleared.
Exercise caution when performing the action.
Procedure
l
Run the reset bgp vpn-instance vpn-instance-name ipv4-family [ ipv4-address ]flapinfo command in the user view to clear statistics of the BGP peer flap for a specified VPN
Run the reset bgp vpn-instance vpn-instance-name ipv4-family dampening [ ipv4address [ mask | mask-length ] ] command in the user view to clear dampening information
of the VPN instance IPv4 address family.
----End
2.15.5 Resetting BGP Connections

After BGP configurations are changed, you can validate the new configurations through a soft
reset or a reset of the BGP connection. Note that resetting the BGP connection leads to VPN
service interruptions.
Issue 02 (2012-03-30)

124

Context
CAUTION
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.
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.
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.
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.
Run the reset bgp vpn-instance vpn-instance-name ipv4-family { as-number | ipv4address | group group-name | all | internal | external } command in the user view to reset
BGP connections of the VPN instance IPv4 address family.
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

This section provides several configuration examples of VPN networking. In each configuration
example, the networking requirements, configuration roadmap, configuration notes,
configuration procedures, and configuration files are described.
2.16.1 Example for Configuring BGP/MPLS IP VPN

This section describes how to configure the basic BGP/MPLS IP VPN, which involves the
configurations of MPLS LSPs, VPNv4 peers, and VPN instances.
As shown in Figure 2-2:
Issue 02 (2012-03-30)

125

CE1 and CE3 are in VPN-A.
CE2 and CE4 are in VPN-B.
The VPN target attribute of VPN-A is 111:1, and that of VPN-B is 222:2.
Users in different VPN cannot access each other.
Figure 2-2 BGP/MPLS IP VPN networking diagram

AS: 65410
AS: 65430
VPN-A
VPN-A
CE1
CE3
Eth1/0/0
10.3.1.1/24
Eth1/0/0
10.1.1.1/24
Eth1/0/0
10.1.1.2/24
Loopback1
1.1.1.9/32
Eth2/0/0
10.2.1.2/24
Loopback1
2.2.2.9/32
PE1
Eth2/0/0
PE2
172.2.1.1/24
Eth1/0/0
172.1.1.2/24
Eth3/0/0
172.1.1.1/24
Eth3/0/0
172.2.1.2/24
MPLS backbone
Eth1/0/0
10.3.1.2/24
Loopback1
3.3.3.9/32
Eth2/0/0
10.4.1.2/24
AS: 100
Eth1/0/0
10.2.1.1/24
Eth1/0/0
10.4.1.1/24
CE2
CE4
VPN-B
VPN-B
AS: 65420
AS: 65440
1.
Configure OSPF on the backbone network to enable interworking between PEs.
2.
Configure the basic MPLS functions and MPLS LDP on the PEs, and establish the MPLS
LSPs between the PEs.
3.
Configure MP IBGP to exchange the VPN routing information between the PEs.
4.
Configure the VPN instance on the PE connected with the CE in the backbone network,
and bind the PE interface connected with the CE to the corresponding VPN instance.
5.
Configure EBGP between the CE and the PE to exchange VPN routing information.
Data Preparation
To configure BGP/MPLS IP VPN, you need the following data:
l
MPLS LSR-IDs on the PEs and the Ps
RDs of VPN-A and VPN-B
Issue 02 (2012-03-30)

126

VPN targets of VPN-A and VPN-B
Procedure
Step 1 Configure an IGP on the MPLS backbone to allow the PEs and the Ps to reach each other.
# Configure PE1.
<Huawei> system-view
[Huawei] sysname PE1
[PE1] interface loopback 1
[PE1-LoopBack1] ip address 1.1.1.9 32
[PE1-LoopBack1] quit
[PE1] interface ethernet3/0/0
[PE1-Ethernet3/0/0] ip address 172.1.1.1 24
[PE1-Ethernet3/0/0] quit
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
# Configure the P.
[Huawei] sysname P
[P] interface loopback 1
[P-LoopBack1] ip address 2.2.2.9 32
[P-LoopBack1] quit
[P] interface ethernet 1/0/0
[P-Ethernet1/0/0] ip address 172.1.1.2 24
[P-Ethernet1/0/0] quit
[P-Ethernet2/0/0] ip address 172.2.1.1 24
[P] ospf
[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] sysname PE2
[PE2] interface loopback 1
[PE2-LoopBack1] ip address 3.3.3.9 32
[PE2-LoopBack1] quit
[PE2] interface ethernet 3/0/0
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
After the configuration, the OSPF neighbor relationship should be established between PE1 and
the P and between the P and PE2. After running the display ospf peer command, you can find
that the OSPF neighbor relationship is in Full state. Run the display ip routing-table command
on the PEs, and you can find that the PEs have learned the routes of the Loopback1 interface of
each other.
Issue 02 (2012-03-30)

127

Use PE1 as an example:

[PE1] display ip routing-table
Destinations : 8
Routes : 8
Flags NextHop
Interface
1.1.1.9/32 Direct 0
0
D 127.0.0.1
InLoopBack0
2.2.2.9/32 OSPF
10
2
D 172.1.1.2
Ethernet3/0/0
3.3.3.9/32 OSPF
10
3
D 172.1.1.2
Ethernet3/0/0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
172.1.1.0/24 Direct 0
0
D 172.1.1.1
Ethernet3/0/0
172.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
172.2.1.0/24 OSPF
10
2
D 172.1.1.2
Ethernet3/0/0
[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(Ethernet3/0/0)'s neighbors
Router ID: 2.2.2.9
Address: 172.1.1.2
State: Full Mode:Nbr is Master Priority: 1
DR: None
BDR: None
MTU: 1500
Dead timer due in 38 sec
Neighbor is up for 00:02:44
Authentication Sequence: [ 0 ]
Step 2 Configure basic MPLS capabilities and MPLS LDP on the MPLS backbone network to set up
the LDP LSP.
# Configure PE1.
[PE1] mpls lsr-id 1.1.1.9
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1-Ethernet3/0/0] mpls
[PE1-Ethernet3/0/0] mpls ldp
# Configure the P.
[P] mpls lsr-id 2.2.2.9
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
[P-Ethernet1/0/0] mpls
[P-Ethernet1/0/0] mpls ldp
[P-Ethernet2/0/0] mpls
[P-Ethernet2/0/0] mpls ldp
# Configure PE2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2-Ethernet3/0/0] mpls
[PE2-Ethernet3/0/0] mpls ldp
Issue 02 (2012-03-30)

128

After the configuration, LDP sessions are set up between PE1 and the P and between the P and
PE2. After running the display mpls ldp session command on the routers, you can find that the
status of the session is "Operational" in the display result. Run the display mpls ldp lsp
command, and view the status of the LDP LSP.
Use PE1 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
------------------------------------------------------------------------2.2.2.9:0
Operational DU Passive 0000:00:01 5/5
------------------------------------------------------------------------TOTAL: 1 session(s) Found.
[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
2.2.2.9/32
NULL/3
172.1.1.2
Ethernet3/0/0
2.2.2.9/32
1024/3
2.2.2.9
172.1.1.2
Ethernet3/0/0
3.3.3.9/32
NULL/1025
172.1.1.2
Ethernet3/0/0
3.3.3.9/32
1025/1025
2.2.2.9
172.1.1.2
Ethernet3/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 in GR state
A '*' before a NextHop means the LSP is FRR LSP
Step 3 Establish the MP-IBGP peer relationship between the PEs.

# Configure PE1.
[PE1] bgp 100
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp] quit
After the configuration, run the display bgp peer command or the display bgp vpnv4 all peer
command, you can see that the BGP peer relationship is set up between the PE and the CE, and
the peer status is Established.
[PE1] display bgp vpnv4 all peer
Peer
V
AS MsgRcvd
Issue 02 (2012-03-30)
MsgSent

OutQ Up/Down
State

PrefRcv
129

3.3.3.9

100
12
18
00:09:38
Established
Step 4 Configure VPN instances on PEs and bind the instances to the CE interfaces.
# 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-af-ipv4] quit
[PE1-vpn-instance-vpnb] quit
[PE1-Ethernet1/0/0] ip binding vpn-instance vpna
[PE1-Ethernet2/0/0] ip binding vpn-instance vpnb
# Configure PE2.
# Configure an IP address for the CE interface according to Figure 2-2. Details for the
configuration procedure are not provided here.
After the configuration, check the configuration of VPN instances by running the display ip
vpn-instance verbose command on the PEs. Each PE can successfully ping its own CE.
NOTE
When the interfaces on a PE are bound to the same VPN, you need to specify the source IP address when
you use the ping command to ping the CE connected to the peer PE. This means that you need to specify
-a source-ip-address in the ping -a source-ip-address -vpn-instance vpn-instance-name dest-ip-address
command; otherwise, the ping fails.
Use PE1 and CE1 as an example:

[PE1] display ip vpn-instance verbose
VPN-Instance Name and ID : vpna, 1
Interfaces : Ethernet1/0/0
Issue 02 (2012-03-30)

130

Address family ipv4

Create date : 2009/01/21 11:30:35
Label Policy : label per route
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
Log Interval : 5
VPN-Instance Name and ID : vpnb, 2
Interfaces : Ethernet2/0/0
Address family ipv4
Create date : 2009/01/21 11:31:18
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
Log Interval : 5
[PE1] ping -vpn-instance vpna 10.1.1.1
0.00% packet loss
Step 5 Establish the EBGP peer relationship between the PE and the CE to import VPN routes.
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] peer 10.1.1.2 as-number 100
[CE1-bgp] import-route direct
NOTE
The configuration procedures of CE2, CE3 and CE4 are similar to that of CE1.
# Configure PE1.
[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
NOTE
The configuration of PE2 is similar to that of PE1, and the details for the configuration procedure are not
provided here.
After the configuration, run the display bgp vpnv4 all peer command on the PE. You can see
that the BGP peer relationship is set up between the PE and the CE, and the peer status is
Established.
Use the peer relationship between PE1 and CE1 as an example.
Issue 02 (2012-03-30)

131

[PE1] display bgp vpnv4 vpn-instance vpna peer

Peer
V
AS MsgRcvd MsgSent
OutQ Up/Down
State
PrefRcv
10.1.1.1
4
65410 11
9
0
00:06:37
Established 1

Running the display ip routing-table vpn-instance command on the PE, you can find the route
to peer CEs.
Use PE1 as an example.
[PE1] display ip routing-table vpn-instance vpna
Destinations : 3
Routes : 3
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24
Direct 0
0
D
10.1.1.2
Ethernet1/0/0
10.1.1.2/32
Direct 0
0
D
127.0.0.1
InLoopBack0
10.3.1.0/24
IBGP
255 0
RD
3.3.3.9
Ethernet3/0/0
[PE1] display ip routing-table vpn-instance vpnb
-----------------------------------------------------------------------------Routing Tables: vpnb
Destinations : 3
Routes : 3
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
10.2.1.0/24
Direct 0
0
D
10.2.1.2
Ethernet2/0/0
10.2.1.2/32
Direct 0
0
D
127.0.0.1
InLoopBack0
10.4.1.0/24
IBGP
255 0
RD
3.3.3.9
Ethernet3/0/0
The CEs in the same VPN can successfully ping each other whereas two CEs in different VPNs
cannot ping each other.
For example, CE1 can successfully ping CE3 (10.3.1.1/24) but cannot ping CE4 (10.4.1.1/24).
[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
ms
ms
ms
ms
ms
----End
Issue 02 (2012-03-30)

132

Configuration Files
l

#
sysname PE1
#
ip vpn-instance vpna
ipv4-family
#
ip vpn-instance vpnb
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
interface Ethernet1/0/0
ip binding vpn-instance vpna
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
#
ipv4-family vpn-instance vpna
import-route direct
#
ipv4-family vpn-instance vpnb
import-route direct
#
ospf 1
area 0.0.0.0
network 172.1.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
#
return
Configuration file of the P

#
sysname P
Issue 02 (2012-03-30)

133

#
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 172.1.1.0 0.0.0.255
network 172.2.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 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
Issue 02 (2012-03-30)

134

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 172.2.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
#
return

#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
peer 10.1.1.2 enable
#
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
#
Issue 02 (2012-03-30)

135

return

#
sysname CE4
#
ip address 10.4.1.1 255.255.255.0
#
bgp 65440
#
ipv4-family unicast
import-route direct
#
return
2.16.2 Example for Configuring the BGP AS Number Substitution

If two VPN sites have the same AS number, and EBGP connections are established between
PEs and CEs, you must enable the AS number substitution function on the PEs that the two VPN
sites access. Otherwise, EBGP discards the routes of the same AS number.
As shown in Figure 2-3,CE1 and CE2 belong to the same VPN, and access PE1 and PE2
respectively. CE1 and CE2 use the same AS number 600.
Figure 2-3 Networking diagram of BGP AS number substitution
Loopback1
1.1.1.9/32
PE1
GE1/0/0
10.1.1.2/24
GE1/0/0
10.1.1.1/24
CE1
Loopback1
2.2.2.9/32
Loopback1
3.3.3.9/32
GE1/0/0
20.1.1.2/24
GE2/0/0
PE2
30.1.1.2/24
GE1/0/0
10.2.1.2/24
GE2/0/0
GE2/0/0
30.1.1.1/24
20.1.1.1/24
P
Backbone
GE1/0/0
AS 100
10.2.1.1/24
CE2
GE2/0/0
200.1.1.1/24
GE2/0/0
100.1.1.1/24
VPN1
AS 600
VPN1
AS 600
Issue 02 (2012-03-30)

136

1.
Configure IGP on the backbone network to realize the interconnection between PEs and
between the PE and the P.
2.
Set up the MPLS LDP LSP between PEs. Create the VPN instance on the PE. Configure
the CE to access the PE.
3.
Set up the EBGP relationship between the PE and the CE. Import the route of the CE to
the PE.
4.
Configure the BGP AS number substitution on the PE.
Data Preparation
To configure the BGP AS number substitution, you need the following data:
l
MPLS LSR-IDs of the PE and the P
The VPN instances created on the PE1 and PE2
The same AS number used by the CE1 and the CE2 (It is different from the AS number of
the backbone network.)
Procedure
Step 1 Configure basic BGP/MPLS IP VPN.
The configuration of basic BGP/MPLS IP VPN includes:
l Configure OSPF on the MPLS backbone network. PE and P can learn routes of the Loopback
interface from each other.
l Configure MPLS basic capability and MPLS LDP on the MPLS backbone network to
establish LDP LSP.
l Establish the MP-IBGP neighbor between PEs to advertise VPN-IPv4 routes.
l Configure the VPN instances of VPN1 on PE2 and associate it with CE2.
l Configure the VPN instances of VPN1 on PE1 and associate it with CE1.
l Configure BGP between PE1 and CE1, and between PE2 and CE2 to import CEs routes into
PEs.
After the configuration given above, run the display ip routing-table command on CE2. It
shows that CE2 can learn the route of the network segment (10.1.1.0/24) of the interface on CE1
that is connected with PE1. There is no route to the VPN site (100.1.1.0/24) of the CE1. The
same situation occurs on CE1.
[CE2] display ip routing-table
Destinations : 9
Routes : 9
Flags NextHop
Interface
10.1.1.0/24 EBGP
255 0
D
10.2.1.2
10.1.1.1/32 EBGP
255 0
D
10.2.1.2
10.2.1.0/24 Direct 0
0
D
10.2.1.1
10.2.1.2/32 Direct 0
0
D
10.2.1.2
10.2.1.1/32 Direct 0
0
D
127.0.0.1
InLoopBack0
127.0.0.0/8 Direct 0
0
D
127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D
127.0.0.1
InLoopBack0
200.1.1.0/24 Direct 0
0
D
200.1.1.1
200.1.1.1/32 Direct 0
0
D
127.0.0.1
InLoopBack0
Run the display ip routing-table vpn-instance command on PE. It shows that there are routes
to the VPN site of the remote CE in the VPN instances of the PE.
Issue 02 (2012-03-30)

137

Consider PE2 as an example:

[PE2] display ip routing-table vpn-instance vpn1
Destinations : 8
Routes : 8
Flags NextHop
Interface
10.1.1.0/24 EBGP
255 0
RD
1.1.1.9
10.1.1.1/32 EBGP
255 0
RD
1.1.1.9
10.1.1.2/32 EBGP
255 0
RD
1.1.1.9
10.2.1.0/24 Direct 0
0
D
10.2.1.2
10.2.1.1/32 Direct 0
0
D
10.2.1.1
10.2.1.2/32 Direct 0
0
D
127.0.0.1
InLoopBack0
100.1.1.0/24 EBGP
255 0
RD
1.1.1.9
200.1.1.0/24 EBGP
255 0
D
10.2.1.1
Run the display bgp routing-table peer received-routes command on CE2. It shows that CE2
does not receive the route to 100.1.1.0/24.
[CE2] display bgp routing-table peer 10.2.1.2 received-routes
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>
10.1.1.0/24
10.2.1.2
0
100?
*>
10.1.1.1/32
10.2.1.2
0
100?
*
10.2.1.0/24
10.2.1.2
0
0
100?
*>
10.2.1.1/32
10.2.1.2
0
0
100?
Step 2 Substitute the BGP AS number.

# Substitute the BGP AS number on the PEs.
Consider PE2 as an example.
[PE2] bgp 100
[PE2-bgp-vpn1] peer 10.2.1.1 substitute-as
Display the routing information and routing table received by CE2.

[CE2] display bgp routing-table peer 10.2.1.2 received-routes
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>
10.1.1.0/24
10.2.1.2
0
100?
*>
10.1.1.1/32
10.2.1.2
0
100?
*>
10.1.1.2/32
10.2.1.2
0
100 100?
*
10.2.1.0/24
10.2.1.2
0
0
100?
*
10.2.1.1/32
10.2.1.2
0
0
100?
*>
100.1.1.0/24
10.2.1.2
0
100 100?
Destinations : 10
Routes : 10
Flags NextHop
Interface
10.1.1.0/24 EBGP
255 0
D
10.2.1.2
10.1.1.1/32 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
InLoopBack0
10.2.1.2/32 Direct 0
0
D
10.2.1.2
100.1.1.1/24 EBGP
255 0
D
10.2.1.2
Issue 02 (2012-03-30)

138

127.0.0.0/8
Direct
127.0.0.1/32 Direct
200.1.1.0/24 Direct
200.1.1.1/32 Direct

0
0
0
0
0
0
D
D
D
127.0.0.1
127.0.0.1
127.0.0.1
InLoopBack0
InLoopBack0
127.0.0.1
InLoopBack0
Configure the BGP AS number substitution function on the PE1. The GigabitEthernet interfaces
of CE1 and CE2 can then ping through each other.
[CE1] ping -a 100.1.1.1 200.1.1.1
0.00% packet loss
----End
Configuration Files
l

#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
ip address 100.1.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
Issue 02 (2012-03-30)

139

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
Configuration file of P
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
#
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 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
Issue 02 (2012-03-30)

140

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
#
peer 10.2.1.1 substitute-as
import-route direct
#
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 200.1.1.1 255.255.255.0
#
bgp 600
#
ipv4-family unicast
import-route direct
#
return
2.16.3 Example for Configuring Hub and Spoke

In the networking of Hub and Spoke, an access control device is specified in the VPN, and users
Issue 02 (2012-03-30)

141

The communication between the Spoke-CEs is controlled by the Hub-CE in the central site, that
is, the traffic between the Spoke-CEs is forwarded by not only the Hub-PE but also the HubCE, as shown in Figure 2-4.
Figure 2-4 Hub and Spoke networking diagram
AS: 65430
Hub-CE
Eth1/0/0
110.1.1.1/24
Eth2/0/0
110.2.1.1/24
Eth3/0/0
110.1.1.2/24
Eth4/0/0
110.2.1.2/24
Hub-PE
Eth2/0/0
11.1.1.2/24
Eth1/0/0
10.1.1.2/24
Loopback1
1.1.1.9/32
Eth2/0/0
11.1.1.1/24
Eth2/0/0
10.1.1.1/24
Eth1/0/0
100.1.1.2/24
Spoke-PE1
Loopback1
3.3.3.9/32
Loopback1
2.2.2.9/32
Backbone
Spoke-PE2
Eth1/0/0
120.1.1.2/24
AS100
Eth1/0/0
100.1.1.1/24
Eth1/0/0
120.1.1.1/24
Spoke-CE1
AS: 65410
Spoke-CE2
AS: 65420
1.
Set up the MP-IBGP peer relationship between the Hub-PE and Spoke-PE. (There is no
need to set up the MP-IBGP peer relationship between the Spoke-PEs.)
2.
Create a VPN instance on the Spoke-PE and set the Import-Target differenet from the
Export-Target.
3.
Create two VPN instances, namely, vpn_in and vpn_out on the Hub-PE. Set the VPNTarget community attribute received by vpn_in as those advertised by two Spoke-PEs. Set
the VPN target community attribute advertised by vpn_out to be the VPN target community
attribute received by the two Spoke-PEs and to be different from the attributes received by
vpn_out.
4.
Configure EBGP between the CE and the PE.
Issue 02 (2012-03-30)

142

5.
Configure Hub-PE to allow Hub-PE to receive the route with the AS repeated for one time.
Data Preparation
To configure the Hub&Spoke, you need the following data:
l
MPLS LSR IDs on the PEs
The VPN instance name of the Hub-PE and Spoke-PE, RD and the VPN-target
Procedure
Step 1 Configure IGP to implement the inter-networking between the Hub-PE and the Spoke-PE in the
backbone network.
The OSPF is used in this example, and the specific configuration procedures are not mentioned.
After the configuration, the OSPF neighbor relationship is established between each pair of HubPE and Spoke-PE.
After running the display ospf peer command, you can see that the status of the neighbor is
Full.
After running the display ip routing-table command on the PE, you can find that PEs learn the
Lookback routes of each other.
Step 2 Configure the basic MPLS capabilities and MPLS LDP on the backbone networks and establish
LDP LSP.
The specific configuration procedures are not mentioned here.
After the configuration, LDP neighbor relationship is established between the Hub-PE and the
Spoke-PE.
After running the display mpls ldp session command on each device, you can see that the status
of the session is "Operational".
Step 3 Configure VPN instances on each PE and connect the CE to the PE.
NOTE
The Import-Target list of one of the VPN on Hub-PE should include the Export-Targets of all Spoke-PEs.
The Export-Target list of another VPN on Hub-PE should include the Import-Targets of all Spoke-PEs.
# Configure Spoke-PE 1.
<Spoke-PE1> system-view
[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] interface ethernet 1/0/0
[Spoke-PE1-Ethernet1/0/0] ip binding vpn-instance vpna
[Spoke-PE1-Ethernet1/0/0] ip address 100.1.1.2 24
[Spoke-PE1-Ethernet1/0/0] quit
Issue 02 (2012-03-30)

143

[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] interface ethernet 1/0/0
[Spoke-PE2-Ethernet1/0/0] ip binding vpn-instance vpna
[Spoke-PE2-Ethernet1/0/0] ip address 120.1.1.2 24
[Spoke-PE2-Ethernet1/0/0] quit
# Configure Hub-PE.
<Hub-PE> system-view
[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] interface ethernet 3/0/0
[Hub-PE-Ethernet3/0/0] ip binding vpn-instance vpn_in
[Hub-PE-Ethernet3/0/0] ip address 110.1.1.2 24
[Hub-PE-Ethernet3/0/0] quit
[Hub-PE] interface ethernet 4/0/0
[Hub-PE-Ethernet4/0/0] ip binding vpn-instance vpn_out
[Hub-PE-Ethernet4/0/0] ip address 110.2.1.2 24
[Hub-PE-Ethernet4/0/0] quit
# Configure IP addresses of the CE interfaces as shown in Figure 2-4.

The configuration procedures are not mentioned here.
After the configuration, run the display ip vpn-instance verbose command on the PE devices,
and you can see the configurations of VPN instances. Each PE can ping through its attached CEs
using the ping -vpn-instance vpn-name ip-address command.
NOTE
you use the ping command to ping the CE connected with the peer PE. That is, you need to specify -a
source-ip-address in the ping -a source-ip-address -vpn-instance vpn-instance-name dest-ip-address
command; otherwise, the ping fails.
Step 4 Establish EBGP peers between the PE and the CE and import the VPN routes.
NOTE
To accept the routes advertised by Hub-PE, configure the Hub-CE to allow AS number to be repeated once.
You need not allow the AS number to be repeated once on the Spoke-PE because a router does not check
the AS-PATH attribute when the router receives the routes advertised by the IBGP peer.
# Configure Spoke-CE 1.
[Spoke-CE1] bgp
[Spoke-CE1-bgp]
[Spoke-CE1-bgp]
[Spoke-CE1-bgp]
65410
import-route direct
quit
[Spoke-PE1] bgp 100
Issue 02 (2012-03-30)

144

[Spoke-PE1-bgp] ipv4-family vpn-instance vpna

[Spoke-PE1-bgp-vpna] peer 100.1.1.1 as-number 65410
[Spoke-PE1-bgp-vpna] quit
[Spoke-PE1-bgp] quit
# Configure Spoke-CE 2.
[Spoke-CE2] bgp
[Spoke-CE2-bgp]
[Spoke-CE2-bgp]
[Spoke-CE2-bgp]
65420
import-route direct
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] quit
[Spoke-PE2-bgp] quit
# Configure Hub-CE.
[Hub-CE] bgp
[Hub-CE-bgp]
[Hub-CE-bgp]
[Hub-CE-bgp]
[Hub-CE-bgp]
65430
import-route direct
quit
# Configure Hub-PE.
[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] 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] quit
[Hub-PE-bgp] quit
After the configuration, run the display bgp vpnv4 all peer command on each PE devices and
you can see that the BGP peer relationship is established between the PE and the CE.
Step 5 Establish MP-IBGP peers between the PEs
[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
[Spoke-PE2-bgp] peer 2.2.2.9 as-number 100
[Spoke-PE2-bgp] peer 2.2.2.9 connect-interface loopback 1
[Spoke-PE2-bgp] ipv4-family vpnv4
[Spoke-PE2-bgp-af-vpnv4] peer 2.2.2.9 enable
[Spoke-PE2-bgp-af-vpnv4] quit
# Configure Hub-PE.
[Hub-PE] bgp
[Hub-PE-bgp]
[Hub-PE-bgp]
[Hub-PE-bgp]
[Hub-PE-bgp]
Issue 02 (2012-03-30)
100
peer
peer
peer
peer
1.1.1.9
1.1.1.9
3.3.3.9
3.3.3.9
as-number 100
connect-interface loopback 1
as-number 100
connect-interface loopback 1

145

[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
After the configuration, run the display bgp peer or display bgp vpnv4 all peer command on
each PE device. You can see the BGP peer relationship is set up between the PEs, and the status
is Established.
After the configuration, the Spoke-CEs can ping through each other. Run the tracert command,
and you can see that the traffic between Spoke-CEs is forwarded through Hub-CE. You can also
deduce the number of forwarding devices between Spoke-CEs based on the TTL in the Ping
result.
Consider Spoke-CE 1 as an example:
[Spoke-CE1] ping 120.1.1.1
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
1 100.1.1.2 8 ms 2 ms 2 ms
2 110.2.1.2 3 ms 2 ms 2 ms
3 110.2.1.1 3 ms 2 ms 2 ms
4 110.1.1.2 3 ms 2 ms 2 ms
5 120.1.1.2 6 ms 6 ms 6 ms
6 120.1.1.1 6 ms 6 ms 6 ms
Run the display bgp routing-table command on Spoke-CE, and you can see that there are
repetitive AS numbers in AS paths of the BGP routes toward the remote Spoke-CE.
Consider Spoke-CE 1 as an example:
[Spoke-CE1] display bgp routing-table
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?
----End
Configuration Files
l
Configuration file of Spoke-CE 1

#
sysname Spoke-CE1
#
Issue 02 (2012-03-30)

146

ip address 100.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return
Configuration file of Spoke-PE 1

#
sysname Spoke-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
#
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
Configuration file of Spoke-PE 2

#
sysname Spoke-PE2
#
ipv4-family
Issue 02 (2012-03-30)

147


#
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
#
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
Configuration file of Spoke-CE 2

#
sysname Spoke-CE2
#
ip address 120.1.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
Configuration file of Hub-CE

#
sysname Hub-CE
#
ip address 110.1.1.1 255.255.255.0
#
ip address 110.2.1.1 255.255.255.0
#
Issue 02 (2012-03-30)

148

bgp 65430
#
ipv4-family unicast
import-route direct
#
return
Configuration file of Hub-PE

#
sysname Hub-PE
#
ip vpn-instance vpn_in
ipv4-family
#
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
Issue 02 (2012-03-30)

149

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
2.16.4 Example for Configuring Inter-AS VPN Option A

After VPN instances are configured on ASBRs, you can implement the OptionA solution to
manage VPN routes in VRF-to-VRF mode.
As shown in Figure 2-5, CE1 and CE2 belong to the same VPN. The CE1 accesses the network
through the PE1 in AS 100 and the CE2 accesses the network through the PE2 in AS 200.
The Inter-AS BGP/MPLS IP VPN is implemented using Option A. That is, VRF-to-VRF method
is used to manage the VPN routes.
Figure 2-5 Networking diagram of inter-AS VPN
BGP/MPLS Backbone
BGP/MPLS Backbone
AS 200
AS 100
Loopback1
Loopback1
2.2.2.9/32
3.3.3.9/32
GE1/0/0
GE2/0/0
GE2/0/0
GE1/0/0
172.1.1.1/24
192.1.1.1/24 192.1.1.2/24
162.1.1.1/24
Loopback1
Loopback1
ASBR1
ASBR2
1.1.1.9/32
4.4.4.9/32
GE1/0/0
GE1/0/0
172.1.1.2/24
PE1
PE2
162.1.1.2/24
GE2/0/0
10.1.1.2/24
GE1/0/0
10.1.1.1/24
CE1
AS 65001
GE2/0/0
10.2.1.2/24
GE1/0/0
10.2.1.1/24
CE2
AS 65002
Issue 02 (2012-03-30)

150

1.
Set up the EBGP peer relationship between the PE and the CE. Set up the MP-IBGP peer
relationship between the PE and the ASBR
2.
Create the VPN instance on two ASBRs and bind the instance to the interface connected
another ASBR. Set up the EBGP peer relationship between ASBRs
Data Preparation
l
MPLS LSR-ID of the PE and the ASBR
The VPN instance names of the PE and the ASBR, RDs and the VPN-targets
Procedure
Step 1 Configure IGP on the MPLS backbone of AS 100 and AS 200 respectively to make ASBR and
PE can reach each other in the same AS.
OSPF is used as the IGP in this example, the configuration procedure is not mentioned.
NOTE
The 32-bit loopback interface address used as LSR ID should be advertised by OSPF.
After the configuration, the OSPF neighbor relationship should be established between the
ASBR and the PE of the same AS. Run the display ospf peer command to find that the OSPF
neighbor relationship is in "Full" state.
The ASBR and the PE in the same AS can ping through each other and can learn the Loopback
interface address of each other.
Step 2 Configure MPLS basic capability and MPLS LDP on the MPLS backbone of AS 100 and AS
200 respectively to set up LDP LSP.
# Configure basic MPLS capability on PE1 and enable LDP on the interface connecting ASBR1.
<PE1> system-view
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1-GigabitEthernet1/0/0] mpls
[PE1-GigabitEthernet1/0/0] mpls ldp
# Configure basic MPLS capability on ASBR1 and enable LDP on the interface connecting PE1.
<ASBR1> system-view
[ASBR1] mpls lsr-id 2.2.2.9
[ASBR1] mpls
[ASBR1-mpls] quit
[ASBR1] mpls ldp
[ASBR1-mpls-ldp] quit
[ASBR1] interface gigabitethernet1/0/0
[ASBR1-GigabitEthernet1/0/0] mpls
[ASBR1-GigabitEthernet1/0/0] mpls ldp
[ASBR1-GigabitEthernet1/0/0] quit
# Configure basic MPLS capability on ASBR2 and enable LDP on the interface connecting PE2.
<ASBR2> system-view
Issue 02 (2012-03-30)

151

[ASBR2] mpls
[ASBR2-mpls] quit
[ASBR2] mpls ldp
[ASBR2] interface gigabitethernet1/0/0
# Configure basic MPLS capability on PE2 and enable LDP on the interface connecting ASBR2.
<PE2> system-view
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configuration, the LDP neighbor relationship should be established between the PE
and the ASBR in the same AS. Running the display mpls ldp session command on the PE or
ASBR, you can find the session state is "Operational" in the output information.
-------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
-------------------------------------------------------------------------2.2.2.9:0
Operational DU
Passive 0000:00:02 9/9
-------------------------------------------------------------------------TOTAL: 1 session(s) Found.
Step 3 Configure basic BGP/MPLS IP VPN on the MPLS backbone of AS 100 and AS 200 respectively.
NOTE
The VPN target of the VPN instances of the ASBR and the PE in the same AS should match. In different
ASs, the matching of the VPN target attributes of the PEs is unnecessary.
# Configure CE1.
<CE1> system-view
[CE1] interface gigabitethernet 1/0/0
[CE1-GigabitEthernet1/0/0] ip address 10.1.1.1 24
[CE1] bgp 65001
[CE1-bgp] quit
# Configure PE1 to set up the EBGP peer relationship with CE1.

[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 1:1 both
[PE1] interface gigabitethernet 2/0/0
[PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[PE1-GigabitEthernet2/0/0] ip address 10.1.1.2 24
Issue 02 (2012-03-30)

152

[PE1] bgp 100

[PE1-bgp-vpn1] peer 10.1.1.1 as-number 65001
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure PE1 to set up the MP-IBGP peer relationship with ASBR1.

[PE1] bgp 100
# Configure ASBR1 to set up the MP-IBGP peer relationship with PE1.

[ASBR1] bgp 100
[ASBR1-bgp] peer 1.1.1.9 as-number 100
[ASBR1-bgp] peer 1.1.1.9 connect-interface loopback 1
[ASBR1-bgp] ipv4-family vpnv4
[ASBR1-bgp-af-vpnv4] peer 1.1.1.9 enable
[ASBR1-bgp-af-vpnv4] quit
[ASBR1-bgp] quit
NOTE
The configurations of CE2, PE2 and ASBR2 are similar to that of CE1, PE1 and ASBR1 and are not
mentioned here.
After the above configurations, run the display bgp vpnv4 vpn-instance peer command. You
can find the BGP peer relationship between PE and CE is set up, that is the "State" in display is
"Established". Run display bgp vpnv4 all peer to find the BGP peer relationship is "Established"
between the PE and the CE, and between the PE and the ASBR.
[PE1] display bgp vpnv4 vpn-instance vpn1 peer
Peer
V AS MsgRcvd MsgSent OutQ Up/Down
State
PrefRcv
10.1.1.1 4 65001
10
10
2
Peer
V
AS MsgRcvd MsgSent OutQ Up/Down
State PrefRcv
2.2.2.9
4
100
3
7
0
10.1.1.1
4 65001
13
13
Step 4 Configure inter-AS VPN in VRF-to-VRF mode.

# Configure ASBR1. Create a VPN instance and bind it to the interface connected to ASBR2.
(ASBR1 regards ASBR2 as its own CE.)
[ASBR1] ip vpn-instance vpn1
[ASBR1-vpn-instance-vpn1] ipv4-family
[ASBR1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:2
[ASBR1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 both
[ASBR1-vpn-instance-vpn1-af-ipv4] quit
[ASBR1-vpn-instance-vpn1] quit
[ASBR1] interface gigabitethernet 2/0/0
[ASBR1-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[ASBR1-GigabitEthernet2/0/0] ip address 192.1.1.1 24
Issue 02 (2012-03-30)

153

# Configure ASBR2. Create a VPN instance and bind it to the interface connected to ASBR1.
(ASBR2 regards ASBR1 as its CE after configuration.)
[ASBR2] ip vpn-instance vpn1
[ASBR2-vpn-instance-vpn1] ipv4-family
[ASBR2-vpn-instance-vpn1-af-ipv4] route-distinguisher 200:2
[ASBR2-vpn-instance-vpn1-af-ipv4] vpn-target 2:2 both
[ASBR2-vpn-instance-vpn1-af-ipv4] quit
[ASBR2-vpn-instance-vpn1] quit
[ASBR2-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
# Configure ASBR1 to set up the EBGP peer relationship with ASBR2.

[ASBR1] bgp 100
[ASBR1-bgp] ipv4-family vpn-instance vpn1
[ASBR1-bgp-vpn1] peer 192.1.1.2 as-number 200
[ASBR1-bgp-vpn1] import-route direct
[ASBR1-bgp-vpn1] quit
[ASBR1-bgp] quit
# Configure ASBR2 to set up the EBGP peer relationship with ASBR1.

[ASBR2] bgp 200
[ASBR2-bgp] ipv4-family vpn-instance vpn1
[ASBR2-bgp-vpn1] peer 192.1.1.1 as-number 100
[ASBR2-bgp-vpn1] import-route direct
[ASBR2-bgp-vpn1] quit
[ASBR2-bgp] quit
After the above configuration, run the display bgp vpnv4 vpn-instance peer command on
ASBRs, and you can see that the BGP peer relationship is established between the ASBRs.
After the above configuration, the CEs learn interface routes of each other. CE1 and CE2 can
ping through each other.
Consider CE1 as an example.
Destinations : 7
Routes : 7
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24 Direct 0
0
D 10.1.1.1
10.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
10.2.1.0/24 EBGP
255 0
D 10.1.1.2
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
192.1.1.0/24 EBGP
255 0
D 10.1.1.2
192.1.1.2/32 EBGP
255 0
D 10.1.1.2
[CE1] ping 10.2.1.1
Issue 02 (2012-03-30)

154

0.00% packet loss
Run the display ip routing-table vpn-instance command on ASBR to see the information of
the VPN routing table.
[ASBR1] display ip routing-table vpn-instance vpn1
Destinations : 7
Routes : 7
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24 IBGP
255 0
RD 1.1.1.9
10.1.1.1/32 IBGP
255 0
RD 1.1.1.9
10.2.1.0/24 IBGP
255 0
D 192.1.1.2
10.2.1.1/32 IBGP
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
InLoopBack0
192.1.1.2/32 Direct 0
0
D 192.1.1.2
Run the display bgp vpnv4 all routing-table command on the ASBR, and you can see the
VPNv4 routes on the ASBR.
[ASBR1] display bgp vpnv4 all routing-table
*>i
Network
NextHop
MED
LocPrf
10.1.1.0/24
1.1.1.9
100
MED
LocPrf
PrefVal Path/Ogn
0

Network
NextHop
10.2.1.0/24
192.1.1.0
192.1.1.1/32
192.1.1.2
0.0.0.0
192.1.1.2
0.0.0.0
Network
NextHop
*>i
*>
*>
10.1.1.0/24
10.2.1.0/24
192.1.1.0
*>
192.1.1.1/32
1.1.1.9
192.1.1.2
0.0.0.0
192.1.1.2
0.0.0.0
*>
*>
*
*>
PrefVal Path/Ogn
0
0
0
0
0
0
0
MED
LocPrf
100
0
0
0
200?
?
200?
?
PrefVal Path/Ogn
0
0
0
0
0
?
200?
?
200?
?
----End
Configuration Files
l
Issue 02 (2012-03-30)

155

#
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
#
#
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
Configuration file of ASBR1

#
sysname ASBR1
#
Issue 02 (2012-03-30)

156

ipv4-family
#
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
#
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 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 ASBR2
#
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
Issue 02 (2012-03-30)

157

ip address 3.3.3.9 255.255.255.255

#
bgp 200
#
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
#
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
Issue 02 (2012-03-30)

158

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
2.16.5 Example for Configuring Inter-AS VPN Option B

After establishing the single-hop MP-EBGP peer relationship between ASBRs, you can
implement the inter-AS VPN OptionB solution.
As shown in Figure 2-6, the CE1 and the CE2 belong to the same VPN. The CE1 accesses the
network through the PE1 in the AS 100. The CE2 accesses the network through the PE2 in the
AS 200.
The inter-AS BGP/MPLS IP VPN is implemented using Option B:
l
ASBR 1 exchange VPN-IPv4 routes with ASBR 2 by MP-EBGP.
ASBR does not perform VPN target filtering on the received VPN-IPv4 routes.
BGP/MPLS Backbone
BGP/MPLS Backbone
AS 200
AS 100
Loopback1
Loopback1
2.2.2.9/32
3.3.3.9/32
GE1/0/0
GE2/0/0
GE2/0/0
GE1/0/0
172.1.1.1/24
192.1.1.1/24 192.1.1.2/24
162.1.1.1/24
Loopback1
Loopback1
ASBR1
ASBR2
1.1.1.9/32
4.4.4.9/32
GE1/0/0
GE1/0/0
172.1.1.2/24
PE1
PE2
162.1.1.2/24
GE2/0/0
10.1.1.2/24
GE1/0/0
10.1.1.1/24
CE1
AS 65001
Issue 02 (2012-03-30)

GE2/0/0
10.2.1.2/24
GE1/0/0
10.2.1.1/24
CE2
AS 65002
159

1.
Configure IGP on the backbone network to interconnect the ASBR and the PE in the same
AS. Set up MPLS LDP LSP between the ASBR and the PE in the same AS.
2.
Set up the EBGP peer relationship between the PE and the CE. Set up the MP-IBGP peer
relationship between the PE and the ASBR.
3.
Configure the VPN instance on the PE. (There is no need to configure the VPN instance
on the ASBR.)
4.
Enable MPLS on the interface connected ASBRs. Set up the MP-EBGP peer relationship
between ASBRs. Configure no VPN-target filtration on the received VPNv4 routes.
Data Preparation
l
MPLS LSR-ID on the PE and the ASBR
Name, RD and the VPN-Target of the VPN instance configured on the PE1 and PE2
Procedure
Step 1 Configure IGP on MPLS backbone of AS 100 and AS 200 respectively to make the PE and the
P reach each other in the same AS.
OSPF is used as the IGP in this example, the configuration procedure is not mentioned here.
NOTE
The 32-bit loopback interface address used as the LSR ID should be advertised by OSPF.
ASBR and the PE of the same AS. Run the display ospf peer command to find that the status
of the OSPF neighbor relationship is "Full".
The ASBR and the PE in the same AS can learn the Loopback addresses of each other and can
ping through each other.
200 respectively to setup LDP LSP.
For configuration procedures, see Example for Configuring Inter-AS VPN Option A.
Step 3 Configure basic BGP/MPLS IP VPN on the MPLS backbone of AS 100 and AS 200 respectively.
NOTE
The VPN target of the VPN instances of the PE1 and the PE2 should be matched.
For configuration procedures, see the following configuration files.

Step 4 Configure inter-AS VPN Option B mode.
# Configure ASBR 1. Enable MPLS on GigabitEthernet2/0/0 connected with ASBR 2.
<ASBR1> system-view
Issue 02 (2012-03-30)

160


# Configure ASBR 1. Establish MP-EBGP peer with ASBR 2 and perform no VPN target
filtering on the received VPNv4 routes, and then enable ASBR 1 to allocate labels based on the
next hop.
[ASBR1] bgp 100
[ASBR1-bgp] ipv4-family vpnv4
[ASBR1-bgp-af-vpnv4] peer 192.1.1.2 enable
[ASBR1-bgp-af-vpnv4] undo policy vpn-target
[ASBR1-bgp-af-vpnv4] apply-label per-nexthop
[ASBR1-bgp-af-vpnv4] quit
[ASBR1-bgp] quit
NOTE
The configurations of ASBR 2 are similar to that of ASBR 1 and are not mentioned here.

After the above configuration, the CEs can learn the interface routes of each other. CE1 and CE2
can be pinged successfully on each other.
Consider CE1 as an example.
<CE1> display ip routing-table
Destinations : 5
Routes : 5
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24 Direct 0
0
D 10.1.1.1
10.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
10.2.1.0/24 EBGP
255 0
D 10.1.1.2
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
<CE1> ping 10.2.1.1
0.00% packet loss
Run the display bgp vpnv4 all routing-table command on the ASBR, and you can see the
VPNv4 routes on the ASBR.
Consider ASBR 1 for an example.
[ASBR1] display bgp vpnv4 all routing-table
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i 10.1.1.0/24
1.1.1.9
0
100
0
?
*>i 10.1.1.1/32
1.1.1.9
0
100
0
?
Issue 02 (2012-03-30)

161

Network
NextHop
*>
10.2.1.0/24
192.1.1.2
MED
LocPrf
PrefVal Path/Ogn
0
200?
----End
Configuration Files
l

#
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
#
import-route direct
#
Issue 02 (2012-03-30)

162

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
Configuration file of ASBR 1

#
sysname ASBR1
#
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
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 ASBR2
#
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
Issue 02 (2012-03-30)

163

ip address 3.3.3.9 255.255.255.255

#
bgp 200
#
ipv4-family unicast
peer 4.4.4.9 enable
#
ipv4-family vpnv4
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
#
ospf 1
Issue 02 (2012-03-30)

164

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
2.16.6 Example for Configuring Inter-AS VPN Option C

After establishing the multi-hop MP-EBGP peer relationship between PEs of different ASs, you
can implement the inter-AS VPN OptionC solution.
As shown in Figure 2-7, CE1 and CE2 belong to the same VPN. The CE1 accesses the network
through the PE1 in AS 100 and the CE2 accesses the network through the PE2 in AS 200.
The Inter-AS BGP/MPLS IP VPN is implemented using Option C.
BGP/MPLS Backbone
BGP/MPLS Backbone
AS 200
AS 100
Loopback1
Loopback1
2.2.2.9/32
3.3.3.9/32
GE1/0/0
GE2/0/0
GE2/0/0
GE1/0/0
172.1.1.1/24
192.1.1.1/24 192.1.1.2/24
162.1.1.1/24
Loopback1
Loopback1
ASBR1
ASBR2
1.1.1.9/32
4.4.4.9/32
GE1/0/0
GE1/0/0
172.1.1.2/24
PE1
PE2
162.1.1.2/24
GE2/0/0
10.1.1.2/24
GE1/0/0
10.1.1.1/24
CE1
AS 65001
Issue 02 (2012-03-30)

GE2/0/0
10.2.1.2/24
GE1/0/0
10.2.1.1/24
CE2
AS 65002
165

1.
Set up the MP-EBGP peer relationship between PEs in different ASs and configure the
maximum hops between PEs.
2.
Configure the routing policy on the ASBR: Assign MPLS labels to the loopback routes
with MPLS tokens received from the PE in the local AS before advertising the routes to
the remote ASBR; Assign new MPLS labels to the routes advertised to the PE in the local
AS if they are labeled IPv4 routes.
3.
Configure the PE and the ASBR of the local AS to exchange the labeled IPv4 route.
4.
Configure the ASBR and the peer ASBR to exchange the labeled IPv4 route.
Data Preparation
l
MPLS LSR-ID of the PE and the ASBR
The VPN instance configured on the PE, RD and the VPN-target
Routing policies configured on the ASBR
Procedure
Step 1 Configure IGP on the MPLS backbone of AS 100 and AS 200 respectively to make the PE and
the ASBR can reach each other in the same AS.
OSPF is used as IGP in this example, and the configuration procedure is not mentioned here.
NOTE
The 32-bit loopback interface address used as the LSR ID should be advertised by OSPF.
ASBR and the PE of the same AS. Run the display ospf peer command to find the status of the
OSPF neighbor relationship as "Full".
Take PE1 as an example.
<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
DR: None
BDR: None
MTU: 0
The ASBR and the PE in the same AS can learn Loopback addresses of each other and can ping
through each other.
200 respectively to setup LDP LSP.
For configuration procedures, see Example for Configuring Inter-AS VPN Option A.
Step 3 Set up the IBGP peer relationship between the PEs and the ASBRs in the same AS.
Issue 02 (2012-03-30)

166

For detailed configurations, see the following configuration files.

Step 4 Configure the VPN instance on the PE and configure the CE to access the PE.
For the detailed configuration, see the following configuration file.
NOTE
The import VPN-taget configured on PE1 must be the same as the export VPN-target configured on PE2;
the export VPN-taget configured on PE1 must be the same as the import VPN-target configured on PE2.
Step 5 Configure exchange of labeled IPv4 routes.

# Configure PE1. Enable to exchange labeled IPv4 routes with ASBR 1.
[PE1] bgp 100
[PE1-bgp] peer 2.2.2.9 label-route-capability
[PE1-bgp] quit
# Configure ASBR 1. Enable MPLS on GigabitEthernet2/0/0 connected to ASBR 2.

# Configure ASBR 1. Create route policies.

[ASBR1] route-policy
[ASBR1-route-policy]
[ASBR1] route-policy
policy1 permit node 1

apply mpls-label
quit
policy2 permit node 1
if-match mpls-label
apply mpls-label
quit
# Configure ASBR 1. Apply route policies to the routes advertised to PE1 and enable to exchange
label IPv4 routes with PE1.
[ASBR1] bgp 100
[ASBR1-bgp] peer 1.1.1.9 route-policy policy2 export
[ASBR1-bgp] peer 1.1.1.9 label-route-capability
# Configure ASBR 1. Apply route policies to the routes advertised to ASBR 2 and enable to
exchange label IPv4 routes with ASBR 2.
[ASBR1-bgp]
[ASBR1-bgp]
[ASBR1-bgp]
[ASBR1-bgp]

peer 192.1.1.2 route-policy policy1 export
peer 192.1.1.2 label-route-capability
quit
# Configure ASBR1. Advertise the Loopback routes with MPLS tokens of PE1 to ASBR2, and
then to PE2.
[ASBR1] route-policy policy3 permit node 1
[ASBR1-route-policy] if-match mpls-token
[ASBR1-route-policy] quit
[ASBR1] bgp 100
[ASBR1-bgp] network 1.1.1.9 32 route-policy policy3
[ASBR1-bgp] quit
NOTE
The configurations of PE2 and ASBR 2 are similar to that of PE1 and ASBR 1 and are not mentioned here.
Step 6 Establish MP-EBGP peers between PE1 and PE2

# Configure PE1.
Issue 02 (2012-03-30)

167

[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

After the above configuration, the CEs can learn interface routes of each other. CE1 and CE2
can ping through each other.
Consider CE1 as an example:
Destinations : 5
Routes : 5
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24 Direct 0
0
D 10.1.1.1
10.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
10.2.1.0/24 EBGP
255 0
D 10.1.1.2
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
[CE1] ping 10.2.1.1
0.00% packet loss
There is no VPNv4 route on the ASBR. Run the display bgp routing-table label command on
the ASBR to see the label information of the routes.
Consider ASBR1 as an example:
[ASBR1] display bgp routing-table label
Network
NextHop
In/Out Label
*>
1.1.1.9
172.1.1.2
15360/NULL
*>
4.4.4.9
192.1.1.2
15361/15361
----End
Issue 02 (2012-03-30)

168

Configuration Files
l

#
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
peer 4.4.4.9 ebgp-max-hop 10
#
ipv4-family unicast
peer 2.2.2.9 enable
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
Issue 02 (2012-03-30)

169

network 1.1.1.9 0.0.0.0

network 172.1.1.0 0.0.0.255
#
return

#
sysname ASBR1
#
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 route-policy policy3
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
if-match mpls-token
apply mpls-label
#
return

#
sysname ASBR2
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 162.1.1.1 255.255.255.0
mpls
mpls ldp
#
Issue 02 (2012-03-30)

170

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
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
if-match mpls-token
#
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
Issue 02 (2012-03-30)

171

#
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
#
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
#
return
2.16.7 Example for Configuring Inter-AS VPN Option C (Solution

2)
If no MP-IBGP relationships are established between PEs and ASBRs, you can use LDP to
allocate labels for BGP and implement the inter-AS VPN OptionC solution.
As shown in Figure 2-8. CE1 and CE2 belong to the same VPN. CE1 accesses AS100 through
PE1, and CE2 accesses AS200 through PE2.
Issue 02 (2012-03-30)

172

Figure 2-8 Networking diagram of the inter-AS VPN

BGP/MPLS Backbone
AS 100
Loopback1
2.2.2.9/32
GE1/0/0
GE2/0/0
172.1.1.1/24
192.1.1.1/24
Loopback1
1.1.1.9/32
ASBR1
BGP/MPLS Backbone
AS 200
Loopback1
3.3.3.9/32
GE2/0/0
192.1.1.2/24
GE1/0/0
172.1.1.2/24
PE1
GE1/0/0
162.1.1.1/24
Loopback1
4.4.4.9/32
ASBR2
GE1/0/0
162.1.1.2/24
PE2
GE2/0/0
10.1.1.2/24
GE2/0/0
10.2.1.2/24
GE1/0/0
10.1.1.1/24
GE1/0/0
10.2.1.1/24
CE1
AS 65001
CE2
AS 65002
No IBGP peer relationship is needed between a PE and an ASBR. The ASBR learns the labeled
BGP routes of the public network at the remote AS from the peer ASBR. 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 realized.
1.
Advertise the routes of the PE within an AS to the remote PE: Advertise the routes of the
PE within an AS to the remote ASBR through BGP, import these BGP routes to IGP on
the remote ASBR, and then advertise the routes of the PE to the remote PE by using IGP.
2.
Configure a routing policy on the ASBR: Allocate MPLS labels to the the routes with MPLS
tokens received by a PE within the local AS and advertised to the remote ASBR. Allocate
new MPLS labels to the labeled IPv4 routes advertised to the PE within the local AS.
3.
Exchange the labeled IPv4 routes between the local ASBR and the remote ASBR.
4.
Configure an LDP LSP for the labeled BGP routes of the public network on ASBRs.
5.
Establish the MP-EBGP peer relationship between PEs of different ASs, and specify the
maximum hops between PEs because the PEs are generally not directly connected.
Data Preparation
l
MPLS LSR ID of the PE and the ASBR
VPN instance name, RD, and VPN target created on the PE
Routing policy on the ASBR
Issue 02 (2012-03-30)

173

Procedure
Step 1 Configure IGP on the MPLS backbone networks of AS100 and AS200. In this manner, PEs
within each MPLS backbone network can be interconnected with ASBRs.
In this example, IGP adopts OSPF, and the specific configuration steps are not mentioned here.
NOTE
Advertise the 32-bit IP address of the loopback interface, that is, the LSR ID, by using OSPF.
After the configuration, the OSPF neighbor relationship can be established between the ASBR
and the PE in the same AS. Run the display ospf peercommand to find that the neighboring
state is Full.
Take PE1 as an example:
<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
DR: None
BDR: None
MTU: 0
The ASBR and PE in the same AS can learn the IP address of the loopback1 interface of each
other. They can also ping each other successfully.
Step 2 Establish the EBGP peer relationship between the ASBRs.
# Configure ASBR1.
[ASBR1] bgp 100
[ASBR1-bgp] quit
# Configure ASBR2.
[ASBR2] bgp 200
[ASBR2-bgp] quit
After the configuration, run the display bgp peer command on ASBRs to find the adjacency
status is Established.
Take ASBR1 as an example:
[ASBR1] display bgp peer
Peer
AS
MsgRcvd
MsgSent
192.1.1.2
4 200
129
134
OutQ
Up/Down
State
PrefRcv
Step 3 Advertise the routes of a PE in an AS to the remote PE.

# On ASBR1, advertise the loopback address of PE1 to ASBR2.
Issue 02 (2012-03-30)

174


[ASBR1] bgp 100
[ASBR1-bgp] quit
# On ASBR2, advertise the loopback address of PE2 to ASBR1.

[ASBR2] bgp 200
[ASBR2-bgp] quit
# On ASBR1, import BGP routes to OSPF, and advertise the routes of PE2 to PE1 through OSPF.
[ASBR1] ospf 1
[ASBR1-ospf-1] import-route bgp
# On ASBR2, import BGP routes to OSPF, and advertise the routes of PE1 to PE2 through OSPF.
[ASBR2] ospf 1
[ASBR2-ospf-1] import-route bgp
After the configuration, run the display ip routing-table command on the PEs to check the
routing table. Take PE1 as an example:
Destinations : 8
Routes : 8
Destination/Mask
Proto
1.1.1.9/32 Direct
2.2.2.9/32 OSPF
4.4.4.9/32 O_ASE
127.0.0.0/8
Direct
127.0.0.1/32 Direct
172.1.1.0/24 Direct
172.1.1.1/32 Direct
172.1.1.2/32 Direct
Pre
Cost
Flags NextHop
0
10
0
1
D
D
127.0.0.1
172.1.1.1
150
172.1.1.1
0
0
0
0
0
0
D
D
D
127.0.0.1
127.0.0.1
172.1.1.2
172.1.1.1
127.0.0.1
Interface
InLoopBack0
InLoopBack0
InLoopBack0
InLoopBack0
Step 4 Configure basic MPLS functions and MPLS LDP on the MPLS backbone networks of AS100
and AS200 to establish LDP LSP.
# Configure basic MPLS functions on PE1 and enable LDP on the interface connected with
ASBR1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure basic MPLS functions on ASBR1 and enable LDP on the interface connected with
PE1.
[ASBR1] mpls
Issue 02 (2012-03-30)

175

[ASBR1-mpls] quit
[ASBR1] mpls ldp
# Configure basic MPLS functions on ASBR2 and enable LDP on the interface connected with
PE2.
[ASBR2] mpls
[ASBR2-mpls] quit
[ASBR2] mpls ldp
# Configure basic MPLS functions on PE2 and enable LDP on the interface connected with
ASBR2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configuration, the LDP sessions between PE1 and the ASBR1, and between PE2 and
ASBR2 are set up. Run the display mpls ldp session command. You can view that the status is
"Operational". Run the display mpls ldp lsp command, and you can view whether LDP LSPs
are set up.
Take PE1 as an example:
-----------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
-----------------------------------------------------------------------------2.2.2.9:0
Operational DU
Passive 0000:00:01 5/5
-----------------------------------------------------------------------------TOTAL: 1 session(s) Found.
<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
2.2.2.9/32
NULL/3
172.1.1.1
2.2.2.9/32
1024/3
2.2.2.9
172.1.1.1
------------------------------------------------------------------------------TOTAL: 3 Normal LSP(s) Found.
TOTAL: 1 Liberal LSP(s) Found.
TOTAL: 0 Frr LSP(s) Found.
Issue 02 (2012-03-30)

176

A
A
A
A
'*'
'*'
'*'
'*'
before
before
before
before
an LSP means the LSP is not established

a Label means the USCB or DSCB is stale
a UpstreamPeer means the session is in GR state
a NextHop means the LSP is FRR LSP
Step 5 Configure the capability of exchanging labeled IPv4 routes on ASBRs.

# Configure ASBR1: Enable MPLS on GigabitEthernet2/0/0 that connects ASBR2.
# On ASBR1, create the routing policy.

[ASBR1-route-policy] apply mpls-label
# On ASBR1, apply a routing policy to the routes advertised to ASBR2, and enable the labeled
IPv4 route exchange with ASBR2.
[ASBR1] bgp
[ASBR1-bgp]
[ASBR1-bgp]
[ASBR1-bgp]
100
quit
NOTE
The configuration on ASBR2 is similar to that on ASBR1 and not mentioned here. Please refer to the
configuration file.
Step 6 Configure LDP LSPs for the labeled BGP routes of the public network on ASBRs.
# Configure ASBR1.
[ASBR1] mpls
[ASBR1-mpls] lsp-trigger bgp-label-route
[ASBR1-mpls] quit
# Configure ASBR2.
[ASBR2] mpls
[ASBR2-mpls] lsp-trigger bgp-label-route
[ASBR2-mpls] quit
Step 7 Configure the VPN instance on the PEs and configure the CEs to access the instances.
# Configure PE1.
# Configure PE2.
Issue 02 (2012-03-30)

177

After the configuration, run the display ip vpn-instance verbose command on PEs to view the
configurations of VPN instances. Each PE can ping its connected CE successfully.
Take PE1 and CE1 as examples:
[PE1] display ip vpn-instance verbose
VPN-Instance Name and ID : vpn1, 1
Interfaces : GigabitEthernet2/0/0
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
ms
ms
ms
ms

20.00% packet loss
Step 8 Establish the MP-EBGP peer relationship between PE1 and PE2.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 200
[PE2-bgp] quit
Step 9 Set up the EBGP peer relationship between PEs and CEs to import VPN routes.
# Configure CE1.
[CE1] bgp 65001
Issue 02 (2012-03-30)

178


[CE1-bgp] quit
# Configure CE2.
[CE2] bgp
[CE2-bgp]
[CE2-bgp]
[CE2-bgp]
65002
import-route direct
quit
# Configure PE1.
[PE1] bgp 100
[PE1-bgp-vpn1] quit
# Configure PE2.
[PE2] bgp 200
[PE2-bgp-vpn1] quit
After the configuration, run the display bgp vpnv4 vpn-instance peer command on a PE to
find that the BGP peer relationship between the PE and CE is in the Established state.
Take the peer relationship between PE 1 and CE 1 as an example:
[PE1] display bgp vpnv4 vpn-instance vpn1 peer
Peer
10.1.1.1
V
AS
4 65001
MsgRcvd
3
MsgSent
3

OutQ Up/Down
State PrefRcv
1
Step 10 Varify the configuration.

After the preceding configuration, CEs can learn routes of interfaces on each other, and CE1
and CE2 can ping each other successfully.
Take CE1 as an example:
Destinations : 5
Routes : 5
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24
Direct 0
0
D 10.1.1.1
10.1.1.1/32
Direct 0
0
D 127.0.0.1
InLoopBack0
10.2.1.0/24
EBGP
255 0
D 10.1.1.2
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32
Direct 0
0
D 127.0.0.1
InLoopBack0
[CE1] ping 10.2.1.1
Issue 02 (2012-03-30)

179


0.00% packet loss
After the configuration, run the display ip routing-table dest-ip-address verbose command on
ASBR1, you can find that the routes from ASBR1 to PE2 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.
Take ASBR1 as an example:
[ASBR1] display ip routing-table 4.4.4.9 verbose
-----------------------------------------------------------------------------Routing Table : Public
Summary Count : 1
Destination
Protocol
Preference
NextHop
State
Tag
Label
IndirectID
RelayNextHop
TunnelID
:
:
:
:
:
:
:
:
:
:
4.4.4.9/32
BGP
255
192.1.1.2
Active Adv
0
15360
0x0
0.0.0.0
0x6002006
Process ID
Cost
Neighbour
Age
Priority
QoSInfo
Interface
Flags
:
:
:
:
:
:
0
1
192.1.1.2
00h12m53s
0
0x0
: GigabitEthernet2/0/0
: D
Run the display mpls lsp protocol ldp include dest-ip-address verbose on ASBR1 and PE2
respectively, you can find that an LDP LSP is established between ASBR1 and PE2. Besides,
you can find an LDP Ingress LSP on a PE to the remote PE.
[ASBR1] 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
: POPGO
Mpls-Mtu
: -----TimeStamp
: 15829sec
Bfd-State
: ---
----End
Configuration Files
l

#
sysname CE1
#
Issue 02 (2012-03-30)

180

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 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 ASBR1
#
mpls lsr-id 2.2.2.9
mpls
Issue 02 (2012-03-30)

181

lsp-trigger bgp-label-route
#
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
#
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
#
if-match mpls-token
apply mpls-label
#
return

#
sysname ASBR2
#
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
Issue 02 (2012-03-30)

182

#
ospf 1
import-route bgp
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 162.1.1.0 0.0.0.255
#
if-match mpls-token
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
#
Issue 02 (2012-03-30)

183

ip address 10.2.1.1 255.255.255.0

#
bgp 65002
#
ipv4-family unicast
import-route direct
#
return
2.16.8 Example for Configuring HoVPN

After configuring HoVPN, you can enable multiple PEs to play different roles to form a
hierarchical structure. In this manner, these PEs function as one PE, and the performance
requirement for PEs are lowered.
As shown in Figure 2-9:
l
CE1 and CE2 belong to VPN-A and the VPN target is 1:1.
CE1 accesses the backbone network through the UPE and CE2 accesses the network
through the PE.
The UPE, the SPE and the PE are interconnected through OSPF.
Figure 2-9 Networking diagram of HoVPN
Loopback1
Loopback1
3.3.3.9/32
2.2.2.9/32
GE2/0/0
172.2.1.1/24
GE1/0/0
PE
Loopback1 172.1.1.2/24
GE2/0/0
1.1.1.9/32
172.2.1.2/24
SPE
GE2/0/0
172.1.1.1/24
UPE GE1/0/0
10.1.1.2/24
GE1/0/0
10.2.1.2/24
AS: 100
GE1/0/0
10.2.1.1/24
GE1/0/0
10.1.1.1/24
CE1
VPN-A
CE2
AS: 65410
AS: 65420
VPN-A
Issue 02 (2012-03-30)

184

1.
Configure IGP in the backbone network and ensure the PEs can learn the loopback address
from each other.
2.
Configure MPLS LSP between PEs.
3.
Create the VPN instance on the UPE and set up the EBGP peer relationship between the
UPE and the CE1.
4.
Create the VPN instance on the PE and set up the EBGP peer relationship between the PE
and the CE2.
5.
Set up the MP-IBGP peer relationship between the UPE and the SPE, the PE and the SPE.
6.
Create the VPN instance on the SPE. Specify the UPE as the underlayer PE, that is, the
user layer PE. Advertise the default route of the VPN instance to the UPE.
Data Preparation
l
MPLS LSR-ID of the UPE, SPE and PE
VPN instance name, RD and VPN target created on the UPE, SPE and PE
Procedure
Step 1 Configure OSPF on the MPLS backbone network to implement internetworking.
After the configuration, OSPF neighbors are established among UPE, SPE and PE. Run the
display ospf peer command to see the status of the OSPF neighbor relationship is "Full". Run
the display ip routing-table command to see that PEs know loopback routes from each other.
Step 2 Configure basic MPLS capability and MPLS LDP on MPLS backbone networks and establish
LDP LSP.
After the configuration, LDP session can be established among UPE, SPE and PE. Run the
display mpls ldp session command to see that the session state is "Operational". Run the display
mpls ldp lsp command to see LDP LSP is established.
Step 3 Configure PEs and CEs.
# Configure UPE.
<UPE> system-view
[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] interface gigabitethernet 1/0/0
[UPE-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[UPE-GigabitEthernet1/0/0] ip address 10.1.1.2 24
[UPE-GigabitEthernet1/0/0] quit
[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
Issue 02 (2012-03-30)

185

# Configure CE1.
[Huawei] sysname CE1
[CE1] bgp 65410
[CE1-bgp] quit
# Configure PE.
<PE> system-view
[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.
[CE2] bgp 65420
[CE2-bgp] quit
After the configuration, run the display ip vpn-instance verbose command on the PE or UPE
to see the configurations of VPN instances. By running the command ping -vpn-instance, the
PE and UPE can ping the CEs attached to themselves successfully.
NOTE
you use the ping -vpn-instance command to ping the CE connected with the peer PE. That is, you need
to specify -a source-ip-address in the ping -a source-ip-address -vpn-instance vpn-instance-name destip-address command; otherwise, the ping fails.
Step 4 Configure MP-IBGP peer relationship between UPE and SPE, and between PE and SPE.
# Configure UPE.
<UPE> system-view
[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 SPE.
Issue 02 (2012-03-30)

186

<SPE> system-view
[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
[SPE-bgp-af-vpnv4] quit
[SPE-bgp] quit
# Configure PE.
<PE> system-view
[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 5 Configure SPE.

# Configure VPN instances.
[SPE] ip vpn-instance vpna
[SPE-vpn-instance-vpna] ipv4-family
[SPE-vpn-instance-vpna-af-ipv4] route-distinguisher 200:1
[SPE-vpn-instance-vpna-af-ipv4] vpn-target 1:1
[SPE-vpn-instance-vpna-af-ipv4] quit
[SPE-vpn-instance-vpna] quit
# Specify a 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 VPN instances to UPE.

[SPE-bgp-af-vpnv4] peer 1.1.1.9 default-originate vpn-instance vpna
[SPE-bgp-af-vpnv4] quit

After the configuration, CE1 does not have a route to the network segment of the interface on
CE2, but has a default route with the next hop to UPE. The CE2 has the route to the network
segment of the interface on CE1. Therefore, CE1 and CE2 can ping through each other using
the ping ip-address command.
<CE1> display ip routing-table
Destinations : 5
Routes : 5
Flags NextHop
Interface
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
InLoopBack0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
[CE1] ping 10.2.1.1
Issue 02 (2012-03-30)

187


0.00% packet loss
Destinations : 5
Routes : 5
Flags NextHop
Interface
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
InLoopBack0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
Run the display bgp vpnv4 all routing-table command on UPE to see a default route of VPN
instances vpna with the next hop to SPE.
[UPE] display bgp vpnv4 all routing-table
*>
*
Network
NextHop
10.1.1.0/24
0.0.0.0
10.1.1.1
MED
LocPrf
0
0
PrefVal Path/Ogn
0
0
?
65410?
*>i
*>i
*>
*
Network
NextHop
MED
LocPrf
0.0.0.0
2.2.2.9
100
Network
NextHop
MED
LocPrf
0.0.0.0
10.1.1.0/24
2.2.2.9
0.0.0.0
10.1.1.1
0
0
0
100
PrefVal Path/Ogn
0
PrefVal Path/Ogn
0
0
0
i
?
65410?
----End
Configuration Files
l

#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
Issue 02 (2012-03-30)

188

import-route direct
#
return
Configuration file of UPE

#
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
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
Configuration file of SPE

#
sysname SPE
#
ipv4-family
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
Issue 02 (2012-03-30)

189

#
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
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
Configuration file of PE
#
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
Issue 02 (2012-03-30)

190

#
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
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
2.16.9 Example for Configuring Multi-VPN-Instance CE

As shown in Figure 2-10, the networking requirements are as follows:
l
CE1 and CE2 belong to the same LAN, and MCE, CE3, and CE4 belong to the same LAN.
An MCE is used by the client to exchange routes between multiple VPN instances.
CE1 and CE3 belong to vpna, while CE2 and CE4 belong to vpnb.
vpna and vpnb use different VPN targets.
The users residing in the same VPN can mutually access, but those in different VPNs cannot
mutually access. So, the services of different VPNs in LAN are isolated from each other.
Issue 02 (2012-03-30)

191

Figure 2-10 Networking diagram of example for Multi-VPN-Instance CE

vpna
vpna
CE1
Eth1/0/0
10.1.1.1/24
Eth1/0/0
10.3.1.1/24
Loopback1
2.2.2.9/32
Eth1/0/0
Eth2/0/0
192.1.1.1/24 192.1.1.2/24
Eth3/0/0
10.3.1.2/24
vpna
Eth1/0/0
Eth3/0/0
Eth2/0/0
Eth2/0/0 PE1 172.1.1.2/24 PE2 192.2.1.1/24 192.2.1.2/24
10.2.1.2/24
MCE
vpnb
Eth4/0/0
10.4.1.2/24
Eth1/0/0
10.2.1.1/24
Eth1/0/0
10.4.1.1/24
Eth1/0/0
10.1.1.2/24
Loopback1
1.1.1.9/32
CE3
Eth3/0/0
172.1.1.1/24
CE2
CE4
vpnb
vpnb
1.
Configure OSPF between the PEs. Configure the MP-IBGP for PEs to distribute VPN
routes learnt from CEs to each other.
2.
Set up EBGP peer relationship between the PE and the connected CE to import the VPN
routes to the VPN routing table of the PE.
3.
Configure the OSPF multi-instance between MCE and PE2 to exchange VPN routes.
Configure RIPv2 between MCE and CE3 to exchange VPN routes. Configure RIPv2
between MCE and CE4 to exchange VPN routes.
NOTE
When configuring OSPF multi-instance between MCE and PE2, configure as follows:
l In the OSPF view of the PE2, (This OSPF process refers to the process used for the configuration of
OSPF multi-instance) import the BGP route. Therefore, the MCE obtains the VPN routes that PE1 has
learned from CE1 or CE2.
l Import the OSPF routes (This OSPF process refers to the process used by the configuration of OSPF
multi-instance) in the BGP view of PE2. In this way, PE1 obtains the VPN route from the MCE.
Data Preparation
To complete this configuration, prepare the following data:
l
A VPN instance for each isolated service is created on PE1, PE2 and MCE. Set the name,
the RD and the VPN target for these VPN instances. Note that, VPN targets of different
VPN instances differ from each other. The VPN targets of the same VPN instance are
matched.
For different OSPF multi-instances, the OSPF process numbers must be different.
Issue 02 (2012-03-30)

192

On the MCE, the RIP process numbers used for importing the VPN routes of the CE3 should
differ from that of the CE4.
Procedure
Step 1 Run OSPF on routers of the backbone network to implement internetworking.
The detailed configuration procedure is not mentioned here.
After this configuration, the PEs can learn the loopback1 address of each other.
<PE2> display ip routing-table
Destinations : 7
Routes : 7
Flags NextHop
Interface
1.1.1.9/32 OSPF
10
2
D 172.1.1.1
Ethernet1/0/0
2.2.2.9/32 Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
172.1.1.0/24 Direct 0
0
D 172.1.1.2
Ethernet1/0/0
172.1.1.1/32 Direct 0
0
D 172.1.1.1
Ethernet1/0/0
172.1.1.2/32 Direct 0
0
D 127.0.0.1
InLoopBack0
Step 2 Enable MPLS and MPLS LDP for PEs to set up an LSP between PEs.
The detailed configuration procedure is not mentioned here. After this configuration, run the
display mpls ldp session command on the PE. You can find that the session status of the MPLS
LDP between the PEs is "operational".
<PE2> display mpls ldp session
-------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
-------------------------------------------------------------------------1.1.1.9:0
Operational DU
Active
0000:00:04 17/17
Step 3 Configure VPN instances for PEs, and connect CE1 and CE2 to PE1, and MCE to PE2.
# Configure PE1.
<PE1> system-view
Issue 02 (2012-03-30)

193


# Configure PE2.
<PE2> system-view
[PE2]interface ethernet3/0/0
Step 4 Configure the VPN instance for MCE, and connect CE3,CE4 and PE2 to MCE.
[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 ethernet3/0/0
[MCE-Ethernet3/0/0] ip binding vpn-instance vpna
[MCE-Ethernet3/0/0] ip address 10.3.1.2 24
[MCE-Ethernet3/0/0] quit
[MCE-Ethernet4/0/0] ip binding vpn-instance vpnb
[MCE-Ethernet1/0/0] ip binding vpn-instance vpna
[MCE-Ethernet2/0/0] ip binding vpn-instance vpnb
Step 5 Set up MP-IBGP peer relationship between PE1 and PE2, and set up EBGP peer relationship
between PE1 and CE1, and between PE1 and CE2.
The detailed configuration procedure is not mentioned here. After this configuration, run the
display bgp vpnv4 all peer command on PE1. You can find the status of IBGP peer relationship
between PE1 and PE2 is "established". The state of EBGP peer relationship between PE1 and
CE1, and between PE1 and CE2 are "established".
Issue 02 (2012-03-30)

194


Peer
V
AS MsgRcvd MsgSent
OutQ Up/Down
State PrefRcv
2.2.2.9
4
100
13
10
6
10.1.1.1
4 65410
9
VPN-Instance vpnb, router ID 1.1.1.9:
10.2.1.1
4 65420
9
11
12
Step 6 Configure OSPF multi-instance between PE2 and MCE.

# Configure PE2.
<PE2> system-view
[PE2] ospf 100 vpn-instance vpna
[PE2-ospf-100] area 0
[PE2-ospf-100] import-route bgp
[PE2-ospf-100] quit
[PE2] ospf 200 vpn-instance vpnb
[PE2-ospf-200] area 0
[PE2-ospf-200] import-route bgp
[PE2-ospf-200] quit
[PE2] bgp 100
[PE2-bgp] ipv4-family vpn-instance vpna
[PE2-bgp-vpna] import-route ospf 100
[PE2-bgp-vpna] quit
[PE2-bgp] ipv4-family vpn-instance vpnb
[PE2-bgp-vpnb] import-route ospf 200
[PE2-bgp-vpnb] quit
# Configure MCE.
<MCE> system-view
[MCE] ospf 100 vpn-instance
[MCE-ospf-100] area 0
[MCE-ospf-100-area-0.0.0.0]
[MCE-ospf-100] quit
[MCE] ospf 200 vpn-instance
[MCE-ospf-200] area 0
[MCE-ospf-200] quit
vpna
network 192.1.1.0 0.0.0.255
quit
vpnb
network 192.2.1.0 0.0.0.255
quit
Step 7 Configure RIPv2 between MCE and CE3, and between MCE and CE4.
# Configure MCE.
[MCE] rip 100
[MCE-rip-100]
[MCE-rip-100]
[MCE-rip-100]
[MCE-rip-100]
[MCE] rip 200
[MCE-rip-200]
[MCE-rip-200]
[MCE-rip-200]
vpn-instance vpna
version 2
network 10.0.0.0
import-route ospf 100
quit
vpn-instance vpnb
version 2
network 10.0.0.0
# Configure CE3.
Issue 02 (2012-03-30)

195

[CE3] rip 100

[CE3-rip-100] version 2
[CE3-rip-100] network 10.0.0.0
[CE3-rip-100] import-route direct
# Configure CE4.
[CE4] rip 200
[CE4-rip-200] version 2
[CE4-rip-200] network 10.0.0.0
[CE4-rip-200] import-route direct
Step 8 Skip the test for loop on MCE, and import RIP routes.
<MCE> system-view
[MCE] ospf 100 vpn-instance vpna
[MCE-ospf-100] vpn-instance-capability simple
[MCE-ospf-100] import-route rip 100
[MCE] ospf 200 vpn-instance vpnb
[MCE-ospf-200] vpn-instance-capability simple
[MCE-ospf-200] import-route rip 200

After the configuration given above, run the display ip routing-table vpn-instance command
on MCE. You can find MCE has a route to each peer CE.
Consider vpna as an example:
[MCE] display ip routing-table vpn-instance vpna
Destinations : 8
Routes : 8
Flags NextHop
Interface
10.1.1.0/24 O_ASE 150 1
D 192.1.1.1
Ethernet1/0/0
10.1.1.1/32 O_ASE 150 1
D 192.1.1.1
Ethernet1/0/0
10.3.1.0/24 Direct 0
0
D 10.3.1.2
Ethernet3/0/0
10.3.1.1/32 Direct 0
0
D 10.3.1.1
Ethernet3/0/0
10.3.1.2/32 Direct 0
0
D 127.0.0.1
InLoopBack0
192.1.1.0/24 Direct 0
0
D 192.1.1.2
Ethernet1/0/0
192.1.1.1/32 Direct 0
0
D 192.1.1.1
Ethernet1/0/0
192.1.1.2/32 Direct 0
0
D 127.0.0.1
InLoopBack0
Run the display ip routing-table vpn-instance command on the PE. You can find PE has a
route to each peer CE.
Consider vpna on PE1 as an example:
[PE1] display ip routing-table vpn-instance vpna
Destinations : 5
Routes : 5
Flags NextHop
Interface
10.1.1.0/24 Direct 0
0
D 10.1.1.2
Ethernet1/0/0
10.1.1.1/32 Direct 0
0
D 10.1.1.1
Ethernet1/0/0
10.1.1.2/32 Direct 0
0
D 127.0.0.1
InLoopBack0
10.3.1.0/24 EBGP
255 2
RD 2.2.2.9
Ethernet3/0/0
192.1.1.0/24 EBGP
255 0
RD 2.2.2.9
Ethernet3/0/0
CE1 and CE3 can ping through each other. Also, CE2 and CE4 can ping through each other.
Consider CE1 as an example:
[CE1] ping 10.3.1.1
PING 10.3.1.1: 56
Issue 02 (2012-03-30)
data bytes, press CTRL_C to break

196

Reply from 10.3.1.1: bytes=56 Sequence=1
0.00% packet loss

ttl=252
ttl=252
ttl=252
ttl=252
ttl=252
time=125
time=125
time=125
time=125
time=125
ms
ms
ms
ms
ms
The CE1 and CE3 can not ping through CE2 and CE4.
Consider the display of ping CE4 on CE1 as an example:
[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

#
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 PE1
Issue 02 (2012-03-30)

197

#
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
#
return

#
sysname PE2
#
ipv4-family
Issue 02 (2012-03-30)

198

#
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
#
#
#
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
#
ospf 200 vpn-instance vpnb
import-route bgp
area 0.0.0.0
network 192.2.1.0 0.0.0.255
#
return
Configuration file of MCE

#
sysname MCE
#
ipv4-family
Issue 02 (2012-03-30)

199


#
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
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
#
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
#
Issue 02 (2012-03-30)

200

rip 200
version 2
network 10.0.0.0
import-route direct
#
return
2.16.10 Example for Connecting VPN and Internet

By configuring a proxy service in the VPN, you can enable the VPN to interconnect with the
Internet.
As shown in Figure 2-11, CE1 and CE2 on the private network can mutually access. Meanwhile
a proxy server with the public network address is attached with CE1. Thus, users of CE1 can
access Internet through this proxy server. In this example, the P device serves as a substitute for
the Internet.
Figure 2-11 Example of enabling VPN users to access the public network
Loopback1
1.1.1.1/32
PE1
GE1/0/0
10.1.1.2/24
GE1/0/0
100.1.1.2/24
GE2/0/0
100.1.1.1/24
GE1/0/0
100.2.1.2/24
GE2/0/0
100.2.1.1/24
Internet
GE1/0/0
10.1.1.1/24
GE2/0/0
100.3.1.2/24
CE1
Loopback1
2.2.2.2/32
vpn1
AS100
Agent Server
100.3.1.1/24
AS 65410
Loopback1
3.3.3.3/32
PE2
GE2/0/0
10.2.1.2/24
GE1/0/0
10.2.1.1/24
CE2
vpn1
AS 65420
In this configuration, configure the L3VPN first. It needs the following static routes:
1.
Add a default route on CE1. The next hop is PE1.
2.
Add a default route from the VPN device to the Internet on PE1. The next hop is P. Thus,
the traffic of the proxy server can reaches the Internet.
3.
Add a static route from the Internet to the proxy server on PE1 and the next hop is CE1.
Use IGP to advertise this route to the Internet, Thus, the traffic of Internet can reaches the
server attached with CE1.
Issue 02 (2012-03-30)

201

Data Preparation
l
MPLS LSR ID on the PEs and the Ps
RD of VPN
VPN-Target of VPN
Procedure
Step 1 Configure IGP.
Assign IP addresses for physical interfaces and loopback interfaces on the backbone network.
Run IGP on each router of the backbone so that PE1, P and PE2 can ping through each other,
and know the loopback address of each other. The detailed configuration procedure is not
mentioned here.
Step 2 Set up an MPLS LDP LSP and MP-IBGP peer relationship.
Set up an MPLS LSP and MP-IBGP peer relationship between the PEs. The detailed
configuration procedure is not mentioned here.
After the configuration given above, run the display mpls ldp session command on P. You can
find the LDP session "Status" between PE1 and P, and that between PE2 and P is "Operational".
The display on P is as follows:
<P> display mpls ldp session
-------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
------------------------------------------------------------------------1.1.1.1:0
Operational DU
Active
0000:00:05 23/23
3.3.3.3:0
Operational DU
Passive 0000:00:04 18/18
Run the display bgp vpnv4 all peer command on PE. You can find that the MP-IBGP peer
relationship state is "Established".
<PE1> display bgp vpnv4 all peer
Peer
V
AS MsgRcvd
3.3.3.3
4
100
6

OutQ Up/Down
State PrefRcv
MsgSent
8
Step 3 Create VPN instances and establishing EBGP.

Create the VPN instance named vpn1 on PE and bind it with the interface attached with the CE.
Establish the EBGP peer relationship between PE1 and CE1, and that between PE2 and CE2.
In this manner, the routes on the CE can be imported to the PE. The detailed configuration
procedure is not mentioned.
After the configuration given above, run the display ip vpn-instance command on PE. You can
find the "VPN instance names" contains vpn1.
Issue 02 (2012-03-30)

202

[PE1] display ip vpn-instance

VPN-Instance Name
Address-family
vpn1
ipv4
Run the command display bgp vpnv4 all peer on PE and you can see that the IBGP peer and
the EBGP peer are "Estabished".
<PE1> display bgp vpnv4 all peer
Peer
V
AS MsgRcvd MsgSent OutQ Up/Down
State
3.3.3.3
4
100
127
134
0 01:39:44
Established
10.1.1.1
4 65410
107
110
0 01:26:33
PrefRcv
2
Established
Step 4 Configure the static route to enable VPN to access the public network.
# Configure a default route on CE1 and the next hop is PE1.
<CE1> system-view
[CE1] ip route-static 0.0.0.0 0 10.1.1.2
# Configure PE1.
# Configure a default route from the proxy server of the VPN site to Internet. The next hop is
P. Specify the address of the next hop as public network address. That is, add a keyword public
after the next hop address in the command.
<PE1> system-view
[PE1] ip route-static vpn-instance vpn1 0.0.0.0 0 100.1.1.2 public
# Configure a static route back to the proxy server. The next hop is CE1.
[PE1] ip route-static 100.3.1.0 24 vpn-instance vpn1 10.1.1.1
# Use IGP to advertise the static route back to the proxy server on PE1 to the Internet.
[PE1] ospf 1
[PE1-ospf-1] import-route static
# Configure the proxy server. Set the IP address of the proxy server as 100.3.1.1/24. Set its
default gateway as CE1, that is, 100.3.1.2/24. A proxy software should also be run on the proxy
server.
Run the display ip routing-table vpn-instance command on PE1. You can find a default route,
with next hop being 100.1.1.2 and the out-interface being GigabitEthernet2/0/0, exists in the
VPN routing table.
[PE1] display ip routing-table vpn-instance vpn1
Destinations : 7
Routes : 7
Flags NextHop
Interface
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.1/32 Direct 0
0
D 10.1.1.1
Issue 02 (2012-03-30)

203

10.1.1.2/32 Direct
10.2.1.0/24 IBGP
10.2.1.1/32 IBGP
10.2.1.2/32 IBGP
100.3.1.1/32 EBGP

0
255
0
0
D
RD
127.0.0.1
3.3.3.3
255
RD
3.3.3.3
255
RD
3.3.3.3
255
InLoopBack0
10.1.1.1
Run the display ip routing-table command on PE1 to display that the route to the proxy server
exists in the public network routing table, and the IP address of next hop is 10.1.1.1.
Destinations : 10
Routes : 10
Flags NextHop
Interface
1.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
2.2.2.2/32 OSPF
10
2
D 100.1.1.2
3.3.3.3/32 OSPF
10
3
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
InLoopBack0
100.1.1.2/32 Direct 0
0
D 100.1.1.2
100.2.1.0/24 OSPF
10
2
D 100.1.1.2
100.3.1.0/24 Static 60
0
D 10.1.1.1
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
P can ping through the proxy server.

[P] ping 100.3.1.1
0.00% packet loss
ms
ms
ms
ms
ms
Also, the proxy server can access P.

----End
Configuration Files
l

#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
ip address 100.3.1.1 255.255.255.0
#
bgp 65410
Issue 02 (2012-03-30)

204


#
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
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 100.3.1.0 24 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
Configuration file of P
#
sysname P
#
Issue 02 (2012-03-30)

205

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
#
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
Issue 02 (2012-03-30)

206

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
Issue 02 (2012-03-30)

207

3 L2TP Configuration
L2TP Configuration
About This Chapter

L2TP is a VPN technology that facilitates the tunneling of PPP frames and allows the Layer 2
termination points and PPP session endpoints to reside on different devices.
3.1 L2TP Overview
The L2TP protocol, which embodies the advantages of L2F and PPTP, is a industry standard on
Layer 2 tunnel protocols defined by the IETF.
3.2 Configuring Basic L2TP Functions
In L2TP configurations, you need to configure basic L2TP functions before configuring other
L2TP functions.
3.3 Configuring LAC
After being configured as an LAC, a device determines whether the user is an access user and
whether to initiate a connection to an LNS.
3.4 Configuring LNS
After receiving a tunnel setup request from an LAC, an LNS checks the authentication method
and determines whether to allow the LAC to set up an L2TP tunnel.
3.5 Adjusting L2TP Connection
After an L2TP tunnel is set up, you can configure or adjust L2TP parameters.
3.6 Maintaining L2TP
This section describes how to disconnect a tunnel forcibly, and monitor the running status of
L2TP.
This section provides L2TP configuration examples.
Issue 02 (2012-03-30)

208

3.1 L2TP Overview

The L2TP protocol, which embodies the advantages of L2F and PPTP, is a industry standard on
Layer 2 tunnel protocols defined by the IETF.
3.1.1 Introduction to L2TP

L2TP messages are used in the maintenance of L2TP tunnels and transmission of PPP frames.
These messages are transmitted through UDP port 1701 in the TCP/IP protocol suite. L2TP uses
two types of messages: control messages and data messages.
The Point to Point Protocol (PPP) defines a kind of encapsulation technique, which ensures the
transmission of datagram of multiple protocols over Layer 2 point-to-point links. During the
transmission, PPP is performed between users and the Network Access Server (NAS), with Layer
2 link endpoints and PPP session termination points residing on the same device.
The Layer 2 Tunneling Protocol (L2TP) is used to transmit the Layer 2 PPP datagram over a
tunnel. L2TP extends the PPP model because L2TP permits Layer 2 link endpoints and PPP
session termination points to stay at different devices, and can realize information exchange
based on packet-switching technology. By combining the advantages of the Layer 2 Forwarding
(L2F) and Point-to-Point Tunneling Protocol (PPTP), L2TP is defined by the Internet
Engineering Task Force (IETF) as an industry standard of the Layer 2 tunneling protocol.
3.1.2 L2TP Features Supported by the AR3200

The AR3200 supports three L2TP tunnel modes.
Three Typical L2TP Tunnel Modes

Figure 3-1 shows the tunnel modes between the remote system and the L2TP Network Server
(LNS), and between the L2TP Access Concentrator (LAC) client (host running L2TP) and LNS.
Figure 3-1 Networking diagram of three typical L2TP tunnel modes
LAC
client
LAC
Remote
system
PSTN/
ISDN
Network
LNS
Internal
server
Network
PC
LAN
LAC
LNS
Issue 02 (2012-03-30)

Internal
server
209

The three methods to establish an L2TP tunnel are as follows:

l
NAS-initialized: initiated by remote users. The remote user connects to the LAC through
Public Switched Telephony Network (PSTN) or Integrated Services Digital Network
(ISDN). The LAC sends a request to the LNS for establishing a tunnel connection through
the Internet. Remote user addresses are assigned by the LNS. The LNS or the agent on the
LAC performs authentication and accounting on the remote user.
Client-initialized: initiated directly by LAC users who support L2TP. In this mode, LAC
clients can send a request for establishing a tunnel connection directly to an LNS, without
the need to pass through the LAC device. The addresses of the LAC clients are assigned
by the LNS.
LAC-Auto-Initiated: In most cases, an L2TP user directly dials up to a LAC, and only PPP
connection is established between the user and LAC. If the LAC serves also as a PPP client,
connection between the user and LAC can be established in other modes in addition to PPP.
The users can send IP packets to the LAC, and then the LAC forwards the packets to the
LNS. To make the LAC serve as a PPP client, create a virtual PPP user and server on the
LAC. The virtual PPP user negotiates with the virtual PPP server, and the virtual PPP server
establishes an L2TP tunnel with the LNS to negotiate with the LNS.
The AR3200 can serve as a LAC and an LNS at the same time, and supports the incoming calls
of multiple concurrent users. If sufficient memory and line capacity are provided, L2TP can
receive and initiate multiple calls at the same time.
3.2 Configuring Basic L2TP Functions

In L2TP configurations, you need to configure basic L2TP functions before configuring other
L2TP functions.

Before configuring basic L2TP functions, familiarize yourself with the applicable environment,
complete the pre-configuration tasks, and obtain the required data. This can help you complete
the configuration task quickly and accurately.
The L2TP group is an important concept that you need to know when configuring L2TP. After
configuring an L2TP group, you can flexibly configure L2TP functions on the device and realize
point-to-point or point-to-multipoint networking applications between the L2TP Access
Concentrator (LAC) and the L2TP Network Server (LNS).
None
Data Preparation
To configure basic L2TP functions, you need the following data.
Issue 02 (2012-03-30)

210

No.
Data
Number of the L2TP group
Names of the tunnels on the LAC side and the LNS side
3.2.2 Configuring Basic L2TP Capability

To configure L2TP, you need to enable L2TP, create an L2TP group, and then configure other
functions. The specific configuration varies with the role of the device (LAC or LNS).
Context
The L2TP groups are numbered separately on the LAC and LNS. To establish the association
between the L2TP groups on LAC and LNS, you need to ensure that the configurations of the
L2TP groups are consistent, such as the received peer name of the tunnel, initiation of the L2TP
connection request, and LNS address.
After creating an L2TP group, you can configure other L2TP functions in the L2TP group view.
The configuration may vary with the role of the device (LAC or LNS).
Perform the following operations on the LAC side and the LNS side.
Procedure
Step 1 Run:
system-view

Step 2 Run:
l2tp enable
L2TP is enabled.
The L2TP functions can be realized only if L2TP is enabled. If L2TP is disabled, the device
cannot offer related L2TP functions even if parameters of L2TP have been configured.
By default, L2TP is disabled, and no L2TP group exists.
Step 3 Run:
l2tp-group group-number
An L2TP group is created and the L2TP group view is displayed.

The group number 1 indicates a default L2TP group.
To receive the request for establishing a tunnel connection from an unknown peer, or meet the
testing requirement, you can create a default L2TP group.
Step 4 Run:
tunnel name tunnel-name
The name of a tunnel at the local end is configured.

You can specify the name of a tunnel at the local end on either the LAC side or the LNS side.
By default, the name of a tunnel at the local end is the host name of the device.
Issue 02 (2012-03-30)

211

NOTE
The name of the tunnel on the LAC side must be the same as the remote end name of the receiving tunnel
on the LNS side.
----End
3.3 Configuring LAC

After being configured as an LAC, a device determines whether the user is an access user and
whether to initiate a connection to an LNS.

Before configuring an LAC, familiarize yourself with the applicable environment, complete the
A device does not send a request for establishing an L2TP tunnel with another device or an LNS
server until certain conditions are met.
To judge whether a user is an access user and whether a connection with the LNS needs to be
established, you must set conditions to distinguish the information about the access user and
specify the IP address of the LNS.
Either of two triggering conditions, namely, a full user name, or the specified domain name of
a user, is needed to initiate the L2TP connection request.
When initiating a tunnel establishment request, the LAC needs to send the source address of the
tunnel to the LNS.
Before configuring the LAC, complete the following tasks:
l
Configuring Basic L2TP Functions
Data Preparation
To configure the LAC, you need the following data.
Issue 02 (2012-03-30)
No.
Data
IP address of the LNS
User full name or domain name used to trigger an L2TP connection
Interface type and interface number used to initiate the request for tunnel establishment
User name and password used for authentication

212

No.
Data
(For RADIUS authentication) Authentication scheme name, RADIUS template name,

IP addresses and interfaces of RADIUS servers, key, and retransmission times
3.3.2 Configuring an L2TP Connection on LAC Side

After receiving a call from an LAC client, an LAC sends a connection request to an LNS in the
configuration sequence of the LNSs. If receiving a response from an LNS, the LNS becomes
the peer of the L2TP tunnel.
Context
Do as follows on the router:
Procedure
Step 1 Run:
system-view

Step 2 Run:
The L2TP group view is displayed.

Step 3 Choose one of the following triggering conditions to initiate a call when the local end is specified
as the LAC:
l If a user accesses the L2TP tunnel by providing the domain name, run the start l2tp { ip ipaddress }&<1-4> domain domain-name command to specify the triggering condition as the
domain name.
l If a user accesses the L2TP tunnel by providing the full user name, run the start l2tp { ip
ip-address }&<1-4> fullusername user-name command to specify the triggering condition
as the full user name.
----End
3.3.3 (Optional) Configuring LAC Auto-Dial

The router initiates virtual private dial-up network (VPDN) dialup and serves as a PPP client
and LAC.
Context
Enterprises expect virtual private networks (VPNs) to be constructed between the headquarters
and branches. The VPN construction costs, however, are high if the enterprises lease resources
from carriers. The VPDN technology allows an enterprise to construct a VPN, and the carrier
needs to provide Internet access for the enterprise. The investments are lowered. Branch routers
establish the VPDN network by dialing up and serve as PPP clients and LACs.
Perform the following steps on the router.
Issue 02 (2012-03-30)

213

Procedure
Step 1 Run:
system-view

Step 2 Run:
interface virtual-template vt-number
A virtual template interface is created and the virtual template interface view is displayed.
Step 3 Configure an IP address for the virtual interface in any of the following methods:
l
Run:
An IP address is configured for the interface.

l
Run:
ip address ppp-negotiate
The dialer interface is configured to obtain an IP address from PPP negotiation.

l
Run:
ip address unnumbered interface interface-type interface-number
The virtual template interface is configured to borrow an IP address from another interface.
Step 4 Run the following command as required.
l
Run:
ppp pap local-user username password { cipher | simple } password
The user name and password in PAP authentication are configured.

l
1.
Run:
ppp chap user username
The user name in CHAP authentication is configured.

2.
Run:
ppp chap password { cipher | simple } password
The password in CHAP authentication is configured.

The user name and password configured on the local device must be the same as those configured
on the remote device. By default, the local device sends a request to the remote device with the
empty user name and password in PAP authentication.
Step 5 Run:
l2tp-auto-client enable
LAC auto-dial is enabled.

Step 6 Run:
quit

Step 7 Run:
ip route-static ip-address { mask | mask-length } virtual-template vt-number
A static route is configured.

Set the destination network segment of the static route to the network segment of the headquarters
and the outbound interface to the virtual PPP interface. After the configurations are complete,
Issue 02 (2012-03-30)

214

packets from users are sent out from the LAC through the PPP interface and reach the LNS
through an L2TP tunnel.
----End
3.3.4 (Optional) Configuring Local Authentication on LAC Side

An LAC authenticates the user through local authentication. The LAC is configured with the
user name and password. Whether the password is in cipher text or in plaintext is determined
by the user. The password in cipher text is more secure.
Context
NOTE
For more information about Authorization, Authentication and Accounting (AAA), refer to the Huawei
AR3200 Series Enterprise Routers Configuration Guide - Security.
Do as followings on the router:
Procedure
Step 1 Run:
system-view

Step 2 Run:
aaa
The AAA view is displayed.

Step 3 Choose one of the following methods to configure the user name and password.
l To configure a password displayed in plain text, run the local-user user-name password
simple password command.
l To configure a password displayed in encrypted text, run the local-user user-name
password cipher password command.
The LAC checks the user name and password of an access user. If they are consistent with the
local registered user name and password, the user is valid. The access user can initiate a tunnel
connection request only after the authentication on the LAC side succeeds.
By default, the LAC side is configured with no user name and password. and the local
authentication is adopted. Therefore, the LAC side must be configured with user name and
password for local authentication.
The password in plain text is a string of 1 to 16 characters and the password in cipher text is a
string of 24 characters.
----End
3.3.5 (Optional) Configuring RADIUS Authentication on LAC Side

An LAC sends the user name and password of the user to the RADIUS server for authentication.
The RADIUS protocol performs centralized management over a large number of dispersed users
and performs authentication, authorization, and accounting on users.
Issue 02 (2012-03-30)

215

Procedure
l
Creating the Authentication and Accounting (AAA) Scheme

1.
Run:
system-view

2.
Run:
aaa

3.
Run:
authentication-scheme authentication-scheme-name
An authentication scheme is created and the view of the authentication scheme is

displayed.
4.
Run:
authentication-mode radius
The authentication mode is specified as RADIUS.

5.
Run:
quit
Return to the AAA view.

6.
Run:
accounting-scheme accounting-scheme-name
An accounting scheme is created and the view of the accounting scheme is displayed.
NOTE
RADIUS accounting is optional.
7.
Run:
accounting-mode radius
The accounting mode is specified as RADIUS.

l
Configuring the RADIUS Template and Related Parameters

1.
Run:
system-view

2.
Run:
radius-server template template-name
A RADIUS server template is created.

3.
Run:
radius-server authentication ip-address port
The IP address and port of the RADIUS authentication server are configured.
4.
Run:
radius-server accounting ip-address port
Issue 02 (2012-03-30)

216

The IP address and port of the RADIUS accounting server are configured.
5.
Run:
radius-server shared-key { cipher | simple
} key-string
The key of the RADIUS server is configured.

6.
Run:
radius-server retransmit retry-times
The retransmitting times of the RADIUS server are configured.

l
Creating a Domain and Applying the RADIUS Template and the Authentication and
Accounting Scheme
1.
Run:
system-view

2.
Run:
aaa

3.
Run:
domain domain-name
The domain is created and the domain view is displayed.

4.
Run:
radius-server template-name
The RADIUS template is applied.

5.
Run:
authentication-scheme authentication-scheme-name
The authentication scheme is applied.

6.
Run:
accounting-scheme accounting-scheme-name
The accounting scheme is applied.

NOTE
The mandatory configurations on the RADIUS service are the user name, password, IP address for
the NAS device to access the RADIUS server, shared key, and port number of the RADIUS server.
The user name and password must be set the same as the user side.
----End

After an LAC is configured, you can view information about L2TP tunnels and L2TP sessions.
Prerequisites
The configurations of the LAC function are complete.
Issue 02 (2012-03-30)

217

Procedure
l
Run the display l2tp tunnel command to check information about the L2TP tunnel.
Run the display l2tp session command to check information about the L2TP session.
Run the display l2tp-group [ group-number ] command to check the configuration about
one special L2TP group.
----End
Example
Run the display l2tp tunnel command on the LAC side. If information about the L2TP tunnel
is displayed, it means the configurations on both the LAC side and the LNS side succeed. For
example:
<Huawei> display l2tp tunnel
Total tunnel = 1
LocalTID RemoteTID RemoteAddress
1
1
202.38.160.1
Port
57344
Sessions RemoteName
1
LAC
Run the display l2tp session command, and you can view that the L2TP session is established.
For example:
<Huawei> display l2tp session
Total session = 1
LocalSID RemoteSID
2036
1469
LocalTID
1
Run the display l2tp-group [ group-number ] command, and you can check the configuration
about one special L2TP group. For example:
<Huawei> display l2tp-group 1
----------------------------------------------L2tp-index
:
1
GroupType
:
REQUEST_DIALIN_L2TP
TunnelAuth
:
Use tunnel authentication
LocalName
:
lac1
TunnelPass
:
huawei
Encrypt
:
0
Hello
:
60
Retransmit
:
5
Timeout
:
2
IfIndex
:
4294967295
SrcIp
:
255.255.255.255
VtNum
:
0
RemoteName
:
ForceChap
:
0
LcpReg
:
0
LcpMismatch
:
0
tunnel each user
:
0
-----------------------------------------------
3.4 Configuring LNS

After receiving a tunnel setup request from an LAC, an LNS checks the authentication method
and determines whether to allow the LAC to set up an L2TP tunnel.
Issue 02 (2012-03-30)

218


Before configuring an LNS, familiarize yourself with the applicable environment, complete the
An LNS offers different virtual templates to receive the tunnel-establishing requests from
different LACs. After receiving one of these requests, the LNS needs to check whether the name
of the LAC (remote end) are valid, and then decide whether to permit the remote end to establish
a tunnel.
After an LAC performs the user authentication, an LNS can re-authenticates the user. That is,
the user is authenticated twice. One is on the LAC, and the other is on the LNS.
After a user passes the authentication on the LNS, the user can communicate with the LNS. If
the user authentication on the LNS fails, L2TP is notified to remove the L2TP connection. In
this manner, an L2TP tunnel is established only after authentications on both the LAC and the
LNS are successful.
The LNS authenticates users in three ways, namely, agent authentication, mandatory CHAP
authentication, and LCP re-negotiation. Among them, the LCP re-negotiation has the highest
priority.
l
LCP re-negotiation
LCP re-negotiation adopts the authentication mode configured on the related virtual
template.
For the NAS-initialized VPN service, a user firstly performs the PPP negotiation with
the NAS when a PPP session starts. If the negotiation is performed well, then NAS
initializes an L2TP tunnel connection, and transmits user information to the LNS. The
LNS then judges whether the user is legal or not based on the received agent
authentication information.
If a more restrict authentication is required on the LNS, or the LNS needs to obtain
certain user information directly (Mostly when the LNS and LAC are from different
providers), LCP re-negotiation needs to be performed between the LNS and the user,
whereas the agent authentication information on the NAS is ignored.
Mandatory CHAP authentication

If only mandatory CHAP authentication is configured, the LNS performs CHAP
authentication for users.
Agent authentication
If neither LCP re-negotiation nor mandatory CHAP authentication is configured, the LNS
performs agent authentication for users. In this authentication mode, the LAC sends all user
authentication information to the LNS. The LNS then authenticate the user information
based on the local configuration.
Suppose the authentication mode configured on the virtual template is CHAP, and that
configured on LAC is PAP when LNS adopts agent authentication. The authentication
cannot pass successfully, because the authentication level of CHAP is higher than that of
PAP.
Issue 02 (2012-03-30)

219

NOTE
After LCP re-negotiation is enabled, if authentication is not configured on the related virtual template, LNS
will not perform secondary authentication for the user. In this manner, the user is authenticated only once
on the LAC.
For other cases, secondary authentication is performed. The authentication mode "none" is also a type of
authentication.
Before configuring the LNS, you need to complete the following tasks:
l
Configuring Basic L2TP Functions
Configuring a virtual template to establish an L2TP connection
Data Preparation
To configure LNS, you need the following data.
No.
Data
Number of the virtual template
Name of remote end in the tunnel
Local user name and password
3.4.2 Configuring an L2TP Connection on LNS

After receiving a tunnel setup request from an LAC, an LNS checks the LAC name and allows
the LAC to set up an L2TP tunnel if the LAC name is a valid name of the remote end. The LNS
can receive the tunnel setup requests from different LACs by using different virtual templates.
Context
Do as follows on LNS:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Choose one of the following commands to configure the name of the remote end of the tunnel.
Issue 02 (2012-03-30)

220

l If the L2TP group number is not 1, run the allow l2tp virtual-template virtual-templatenumber remote remote-name command.
l If the L2TP group number is 1, run the allow l2tp virtual-template virtual-templatenumber [ remote remote-name ] command.
The default L2TP group number is 1. When the group number of L2TP is set to 1, you need not
specify the remote name of the tunnel. If you specify the name of the remote end in the view of
the L2TP group 1, L2TP group 1 will not be regarded as the default L2TP group any more.
NOTE
Only the L2TP group with the group number 1 can be set as the default group.
In the same L2TP group, the start command and the allow l2tp command are mutually exclusive. When
one is configured, the other becomes invalid automatically.
----End
3.4.3 (Optional) Configuring User Authentication on LNS

After an LAC performs user authentication, an LNS can re-authenticates the user. The LNS
authenticates users in three ways, namely, agent authentication, mandatory CHAP
authentication, and LCP re-negotiation. LCP re-negotiation has the highest priority.
Context
NOTE
For more information about AAA, refer to the Huawei AR3200 Series Enterprise Routers Configuration
Guide - Security.
Do as follows on LNS:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Choose one of the following commands to configure the authentication scheme.
l Run the mandatory-lcp command to configure the mandatory LCP re-negotiation.
l Run the mandatory-chap to configure the mandatory local CHAP authentication.
l Skip this step to perform the agent authentication.
By default, the agent authentication is adopted.
Step 4 Run:
quit

Step 5 Run:
aaa
Issue 02 (2012-03-30)

221


Step 6 Choose one of the following commands to configure the user authentication.
l Run the local-user user-name password { simple | cipher } password command to configure
the user name and password if the local authentication is adopted.
The password in plain text is a string of 1 to 16 characters and the password in cipher text is
a string of 24 characters.
l For the mandatory local CHAP authentication, LCP re-negotiation, and agent authentication,
the user name and password for authentication must be set on LNS.
l If the RADIUS authentication is adopted, see 3.3.5 (Optional) Configuring RADIUS
Authentication on LAC Side.
The user name and password configured on LNS must be consistent with those configured on
LAC.
By default, the local authentication is adopted.
----End
3.4.4 Allocating Addresses to Access Users

Users belong to different domains. The users whose domains are not specified belong to the
default domain. After an L2TP tunnel is set up between an LAC and an LNS, the LNS selects
an IP address from the IP address pool of the domain to which the user belongs and then assigns
the IP address to the user.
Context
In the AR3200, each access user belongs to a domain. If a user with no domain specified accesses
an L2TP tunnel, the user uses the default domain. After the L2TP tunnel between the LAC and
LNS is set up, the LNS should assign the IP address for the access user from the address pool
of the user domain.
Procedure
Step 1 For details of the address pool configuration and address assignment, refer to the Huawei
AR3200 Series Enterprise Routers Configuration Guide - IP Services and Configuration Guide
- Security.
----End

After an LNS is configured, you can view information about L2TP tunnels and L2TP sessions.
Prerequisites
The configurations of the LNS function are complete.
Procedure
l
Run the display l2tp tunnel command to check information about the L2TP tunnel.
Run the display l2tp session command to check information about the L2TP session.
Issue 02 (2012-03-30)

222

Run the display l2tp-group [ group-number ] command to check the configuration about
one special L2TP group.
Run the display access-user command to view information about the accessed users.
----End
Example
Run the display l2tp tunnel command. If information about the L2TP tunnel is displayed, it
means the configuration succeeds. For example:
<Huawei> display l2tp tunnel
Total tunnel = 1
1
1
12.1.1.1
Port
1701
Sessions RemoteName
1
LNS
Run the display l2tp session command, and you can view that the L2TP session is established.
For example:
<Huawei> display l2tp session
Total session = 1
LocalSID RemoteSID
1
1
LocalTID
1
Run the display l2tp-group [ group-number ] command, and you can check the configuration
about one special L2TP group. For example:
<Huawei> display l2tp-group 1
----------------------------------------------L2tp-index
:
1
GroupType
:
ACCEPT_DIALIN_L2TP
TunnelAuth
:
Use tunnel authentication
LocalName
:
lns
TunnelPass
:
huawei
Encrypt
:
0
Hello
:
60
Retransmit
:
5
Timeout
:
2
IfIndex
:
4294967295
SrcIp
:
255.255.255.255
VtNum
:
1
RemoteName
:
lac1
ForceChap
:
0
LcpReg
:
0
LcpMismatch
:
0
tunnel each user
:
0
-----------------------------------------------
3.5 Adjusting L2TP Connection

After an L2TP tunnel is set up, you can configure or adjust L2TP parameters.

Before adjusting an L2TP tunnel, familiarize yourself with the applicable environment, complete
the pre-configuration tasks, and obtain the required data. This can help you complete the
Issue 02 (2012-03-30)

223

This section describes the common L2TP configurations, which can be applied for either the
LAC or the LNS.
l
Tunnel authentication: Either an LAC or an LNS can send tunnel authentication requests.
An L2TP tunnel can be established only if both the LAC and the LNS are enabled with the
tunnel authentication, and have the same password (not null). Otherwise, the local end
disconnects the tunnel automatically. If the tunnel authentications are disabled on both ends,
the L2TP tunnel still cannot be established even if the passwords on two ends are the same.
Attribute Value Pair (AVP) hidden transmission: AVP is adopted in the L2TP protocol to
transmit and negotiate some parameter attributes of L2TP. For the sake of security, users
transmit these AVPs in hidden mode.
Hello packets sending: To check the connectivity of a tunnel, the LAC and the LNS send
Hello packets to each other periodically, and the receiver responds the peer within a
specified interval. If no response is received from the peer within the specified interval, the
local end resends the Hello packets. After the Hello packets are resent for more than three
times, the L2TP tunnel is regarded as disconnected. The tunnel connection needs to be reestablished between the LAC and the LNS.
NOTE
All the configurations described in this section are optional. You can take the default settings in most cases.
None
Data Preparation
To adjust the L2TP connection, you need the following data.
No.
Data
Password for tunnel authentication
Interval for sending Hello packets
3.5.2 Configuring Security Options for L2TP Connection

To ensure security, you can enable tunnel authentication on both ends, enable tunnel
authentication before setting up a tunnel, and transmit AVPs in hidden mode.
Context
Do as follows on the LNS side or the LAC:
Procedure
Step 1 Run:
system-view
Issue 02 (2012-03-30)

224


Step 2 Run:

Step 3 Run:
tunnel authentication
The tunnel authentication is enabled.

By default, the tunnel authentication is enabled.
You can decide whether to enable tunnel authentication before establishing a tunnel connection.
To ensure the tunnel security, you are recommended to enable the tunnel authentication.
NOTE
If tunnel authentication is enabled on one end (either the LAC or the LNS), the peer must be enabled with
tunnel authentication.
Step 4 Choose one of the following commands to configure a password.

l Run the tunnel password simple password command to configure a password in plain text.
l Run the tunnel password cipher password command to configure a password in encrypted
text.
By default, the password for tunnel authentication is null.
Step 5 Run:
tunnel avp-hidden
The AVP data is transmitted in hidden mode.

By default, the AVP data is transmitted in plain text. The function of AVP hidden transmission
works only when both ends adopt the tunnel authentication.
----End
3.5.3 Configuring L2TP Connection Parameters

After an L2TP tunnel is set up, you can configure or adjust the interval for sending Hello packets.
Context
Do as follows on the LNS or the LAC:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Issue 02 (2012-03-30)

225

Step 3 Run:
tunnel timer hello interval
The interval for sending Hello packets is set.

By default, the interval for sending Hello packets is 60 seconds.
----End
3.6 Maintaining L2TP

This section describes how to disconnect a tunnel forcibly, and monitor the running status of
L2TP.
3.6.1 Disconnecting a Tunnel Forcibly

When there are no access users, a network fault occurs, or the administrator needs to disconnect
a tunnel, you can run the reset l2tp tunnel command to disconnect the tunnel and the sessions in
the tunnel.
Procedure
l
Run the reset l2tp tunnel { peer-name remote-name | local-id tunnel-id } command to
disconnect the L2TP tunnel forcibly in the user view.
If the parameter peer-name is specified, all the tunnels with this name are cleared. If the
parameter tunnel-id is specified, only the tunnel with this tunnel ID is cleared.
A tunnel is cleared when the number of access users is 0, a network fault occurs, or the
administrator needs to disconnect the tunnel.
In addition, either the LAC or the LNS can request for clearing a tunnel initiatively. The
side receiving the clearing request must reply with the Acknowledgement (ACK) message,
and then wait for a certain period before performing the tunnel clearing operation. In this
manner, even if the ACK message is lost, the side can still have time to receive the resent
clearing request.
After an L2TP tunnel is disconnected forcibly, all control and session connections in the
tunnel are cleared. The tunnel can be re-established when a new user dials in.
----End
3.6.2 Monitoring the Running Status of L2TP

In routine maintenance, you can run the L2TP-related display commands to view the running
status of L2TP.
Context
In routine maintenance, you can run the following commands to view the running status of L2TP.
Procedure
l
Issue 02 (2012-03-30)
Run the display l2tp session command to view information about the L2TP session.
226

Run the display l2tp tunnel command to view information about the L2TP tunnel.
Run the display access-user command to view information about the user sessions.
Run the display l2tp-group command to view information about current L2TP groups.
----End
3.6.3 Debugging L2TP Information

When an L2TP fault occurs, you can run the L2TP related debugging commands to debug L2TP
and locate the fault.
Context
NOTE
Debugging affects the system performance. So, after the debugging, run the undo debugging all command
to disable it immediately.
When an L2TP fault occurs, run the following debugging commands in the user view to debug
L2TP and locate the fault.
For the procedure of outputting the debugging information, see the chapter "Maintenance and
Debugging" in the Huawei AR3200 Series Enterprise Routers Configuration Guide - System
Management.
Procedure
l
Run the debugging l2tp all command in the user view to enable complete L2TP debugging.
Run the debugging l2tp control command in the user view to enable control packet
debugging.
Run the debugging l2tp dump command in the user view to enable PPP packet debugging.
Run the debugging l2tp error command in the user view to enable L2TP error debugging.
Run the debugging l2tp event command in the user view to enable L2TP event debugging.
Run the debugging l2tp hidden command in the user view to enable hidden AVP
debugging.
Run the debugging l2tp payload command in the user view to enable L2TP packet
debugging.
Run the debugging l2tp timestamp command in the user view to enable L2TP time stamp
debugging.
----End

This section provides L2TP configuration examples.
3.7.1 Example for Configuring NAS-Initialized VPNs (Domain

Name Access)
This section provides an example for configuring a NAS-initialized VPN with users accessing
the network through domain names, and the user name and password being authenticated locally
on the LAC and LNS.
Issue 02 (2012-03-30)

227

As shown in Figure 3-2, PC1 connects the Public Switched Telephone Network (PSTN) through
a Modem; and then connects the LAC, namely, Router A, across the PSTN. PC2 connects Router
A through a tunnel. The LAC and the LNS are connected through the Internet. The LAC and
the LNS communicate with each other through a tunnel. Users access the tunnel by using domain
names. On both the LAC and the LNS, the user name and the password are authenticated locally.
NOTE
When the AR3200 communicates with a non-Huawei device, configure the AR3200 to invert clock signals
transmitted by a synchronous serial interface as required.
Figure 3-2 Networking diagram of a NAS-Initialized VPN
Modem
PC1
PSTN
RouterB
RouterA
Internet
ISDN
LNS
LAC
Tunnel
PC2
Server
headquarters
1.
A user intends to communicate with the server in the headquarters. The IP address of the
server is a private address. In this manner, the user cannot access the server directly through
the Internet. A VPN is then needed to help the user access the data of the internal network.
2.
The user accesses the headquarters by using the domain name "huawei.com". The LNS
needs to configure an address pool in this domain that can allocate an IP address for the
user.
Data Preparation
l
Consistent user name, domain name, and password of the router at both the user side and
the LAC side
Protocol used on the LNS side, tunnel authentication mode (CHAP is used), password for
the tunnel, and local and remote names of the LNS
Number, IP address, and network mask of the virtual template
L2TP group number
Number, range, and address mask of the remote address pool
Issue 02 (2012-03-30)

228

Procedure
Step 1 Configure the user side.
Create a dial-in connection, and an access number named Huawei1. In addition, receive the
address assigned by the LNS server.
Enter the user name "vpdnuser@huawei.com" in the dial-up terminal window that pops up, with
the password being Hello. Note that the user name and password should have been registered
on the LNS server of the company.
Step 2 Configure Router A (LAC).
In this example, the IP address of Serial 1/0/0 on the LAC that connects the tunnel is
202.38.160.1; the IP address of Serial 1/0/0 on the LNS that connects the tunnel is 202.38.160.2.
# Configure IP addresses for both serial ports.
[Huawei] sysname RouterA
[RouterA] interface serial 1/0/0
[RouterA-Serial1/0/0] link-protocol ppp
[RouterA-Serial1/0/0] ip address 202.38.160.1 255.255.255.0
[RouterA-Serial1/0/0] quit
# Create an L2TP group and configure related attributes.

[RouterA] l2tp enable
[RouterA] l2tp-group 1
[RouterA-l2tp1] tunnel name LAC
[RouterA-l2tp1] start l2tp ip 202.38.160.2 domain huawei.com
# Enable the tunnel authentication and set a tunnel authentication password.

[RouterA-l2tp1] tunnel authentication
[RouterA-l2tp1] tunnel password simple quidway
[RouterA-l2tp1] quit
# Set the user name and password. Note that the user name and password must be consistent
with those set on the user side.
[RouterA] aaa
[RouterA-aaa] local-user vpdnuser@huawei.com password simple Hello
[RouterA-aaa] local-user vpdnuser@huawei.com service-type ppp
# Create a domain that users access.

[RouterA-aaa] domain huawei.com
Step 3 Configure Router B (LNS).

# Configure an IP address for Serial 1/0/0 on the LNS.
[Huawei] sysname RouterB
[RouterB] interface serial 1/0/0
[RouterB-Serial1/0/0] link-protocol ppp
[RouterB-Serial1/0/0] ip address 202.38.160.2 255.255.255.0
[RouterB-Serial1/0/0] quit
# Create a virtual template and configure related parameters.

[RouterB] interface virtual-template 1
[RouterB-Virtual-Template1] ip address 192.168.0.1 255.255.255.0
[RouterB-Virtual-Template1] ppp authentication-mode chap
[RouterB-Virtual-Template1] quit
Issue 02 (2012-03-30)

229

# Enable L2TP and create an L2TP group.

[RouterB] l2tp enable
[RouterB] l2tp-group 1
# Configure the name of the local end and the name of the peer.
[RouterB-l2tp1] tunnel name LNS
[RouterB-l2tp1] allow l2tp virtual-template 1 remote LAC
# Enable the tunnel authentication and set a tunnel authentication password.

[RouterB-l2tp1] tunnel authentication
[RouterB-l2tp1] tunnel password simple quidway
# Configure the mandatory local CHAP authentication.

[RouterB-l2tp1] mandatory-chap
[RouterB-l2tp1] quit
# # Set the user name and password. Note that the user name and password must be consistent
with those set on the LAC side.
[RouterB] aaa
[RouterB-aaa] local-user vpdnuser@huawei.com password simple Hello
[RouterB-aaa] local-user vpdnuser@huawei.com service-type ppp
# Configure a domain that users access.

[RouterB-aaa] domain huawei.com
[RouterB-aaa-domain-huawei.com] quit
[RouterB-aaa] quit
# Set an address pool to assign addresses to dial-in users.

[RouterB] ip pool 1
[RouterB-ip-pool-1]network 192.168.0.0 24

After VPN users log into the tunnel, run the display l2tp tunnel command. You can find that
the tunnel is set up. Take the display on the LNS as an example:
[RouterB] display l2tp tunnel
Total tunnel = 1
1
1
202.38.160.1
Port
57344
Sessions RemoteName
1
LAC
Run the display l2tp session command. You can check whether the L2TP session is set up. Take
the display on the LNS side as an example.
[RouterB] display l2tp session
Total session = 1
LocalSID RemoteSID
2036
1469
LocalTID
1
In this manner, VPN users can access the server in the headquarters.
----End
Configuration Files
l

#
sysname RouterA
Issue 02 (2012-03-30)

230

#
l2tp
enable
#
aaa
authentication-scheme
default
authorization-scheme
default
accounting-scheme
default
domain
default
domain
default_admin
domain
huawei.com
local-user vpdnuser@huawei.com password simple
Hello
local-user vpdnuser@huawei.com service-type
ppp
#
interface
Serial1/0/0
link-protocol
ppp
ip address 202.38.160.1
255.255.255.0
#
l2tp-group
1
tunnel password simple
quidway
tunnel name
LAC
start l2tp ip 202.38.160.2 domain
huawei.com
#
return

#
sysname RouterB
#
ip pool
1
network 192.168.0.0 mask
255.255.255.0
#
aaa
authentication-scheme
default
authorization-scheme
default
accounting-scheme
default
domain
default
domain
huawei.com
local-user vpdnuser@huawei.com password simple
Hello
local-user vpdnuser@huawei.com service-type
ppp
#
interface VirtualTemplate1
ppp authentication-mode
chap
ip address 192.168.0.1
Issue 02 (2012-03-30)

231

255.255.255.0
#
interface
Serial1/0/0
link-protocol
ppp
ip address 202.38.160.2
255.255.255.0
#
l2tp-group
1
mandatorychap
allow l2tp virtual-template 1 remote
LAC
tunnel password simple
quidway
tunnel name
LNS
#
return
3.7.2 Example for Configuring NAS-Initialized VPNs (Dialup

Access)
This section provides an example for configuring a NAS-initialized VPN with VPN users
accessing the NAS through the PSTN or ISDN.
As shown in Figure 3-3, Users access the NAS through the PSTN or the Integrated Services
Digital Network (ISDN). The LNS, namely, Router A, connects the NAS through the Internet.
Figure 3-3 Networking diagram of NAS-initialized VPN
Internet
PSTN/ISDN
VPN
Client
Tunnel
NAS
RouterA
LNS
Headquarters
The procedure for a user to access the headquarters is as follows:
1.
A user dials in the PSTN or ISDN.
2.
The NAS performs the user authentication. If the user is found to be a VPN user, the NAS
sends a tunnel-connecting request to the LNS.
3.
After a tunnel between the NAS and the LNS is set up, the NAS sends the information
about the negotiation with the VPN user as the contents of the packets to the LNS.
4.
The LNS decides whether to accept the connecting request according to the negotiated
information.
Issue 02 (2012-03-30)

232

5.
The user communicates with the headquarters by using the tunnel between the NAS and
the LNS.
6.
The user accesses the headquarters network by using the default domain (the domain name
is "default") and adopts the local authentication. The addresses are allocated from the
address pool. In this mode, the address pool should be configured in the AAA view of the
LNS.
Data Preparation
l
User name, password, and access code of the VPN
User name and password for the Remote Authentication Dial in User Service (RADIUS)
authentication (the same as user name and password of the VPN)
On the LNS router, number of the virtual template, IP address and mask of the template,
and L2TP group number
Procedure
Step 1 Configure the user side.
Enter the VPN user name "vpdnuser", the password "Hello", and the access code "170" in the
dial-up network window. Then enter the user name and password for the RADIUS authentication
in the dial-up terminal window.
Step 2 Configure NAS.
In this example, the access server is used as the LAC device.
# Set 170 as the access code on the access server.
# On the RADIUS access server, set the user name and password for a VPN user, and set the IP
address for the corresponding LNS device. (In this example, the IP address of the LNS interface
connected with the tunnel is 202.38.160.2.)
# Define the local device name as A8010, and fulfill the tunnel authentication. The password
used in the tunnel authentication is "huawei".
NOTE
To configure A8010, refer to the corresponding A8010 manuals.
Step 3 Configure the LNS router.

# Configure an IP address for Serial 1/0/0.
# Create a virtual template and configure related parameters.

[RouterA] interface virtual-template 1
[RouterA-Virtual-Template1] ip address 192.168.0.1 255.255.255.0
[RouterA-Virtual-Template1] ppp authentication-mode chap
Issue 02 (2012-03-30)

233

[RouterA-Virtual-Template1] remote address pool 1

[RouterA-Virtual-Template1] quit
# Enable L2TP and create an L2TP group.

# Configure the name of the tunnel local end and the peer end on LNS.
[RouterA-l2tp1] tunnel name LNS
[RouterA-l2tp1] allow l2tp virtual-template 1 remote A8010
# Enable the tunnel authentication and set the password.

[RouterA-l2tp1] tunnel password simple huawei
# Create an address pool and assign an address to a dial-in user.

[RouterA] ip pool 1
[RouterA-ip-pool-1]network 192.168.0.0 mask 24
# Set the user name and password, which must be the same as those set on the user side.
[RouterA] aaa
[RouterA-aaa] local-user vpdnuser password simple Hello
[RouterA-aaa] local-user vpdnuser service-type ppp
[RouterA-aaa] quit

After VPN users log in to the LAC or LNS devices, run the display l2tp tunnel command and
you can find the tunnel is set up. Take the display on the LAC as an example:
<RouterA> display l2tp tunnel
Total tunnel = 1
1
1
202.38.160.3
Port
1701
Sessions RemoteName
1
A8010
Running the display l2tp session command, you can check whether sessions are set up. Take
the display on the LNS as an example.
<RouterA> display l2tp session
Total session = 1
LocalSID RemoteSID
1469
2036
LocalTID
1
In this manner, the VPN user can access the network of the headquarters.
----End
Configuration Files
NOTE
Only the configuration file of the LNS is listed.

#
sysname RouterA
#
l2tp enable
#
ip pool 1
network 192.168.0.0 mask 255.255.255.0
#
Issue 02 (2012-03-30)

234

aaa
authentication-scheme default
authorization-scheme default
accounting-scheme default
local-user vpdnuser password simple Hello
local-user vpdnuser service-type ppp
#
interface Virtual-Template1
ppp authentication-mode chap
remote address pool 1
ip address 192.168.0.1 255.255.255.0
#
interface Serial 1/0/0
link-protocol ppp
ip address 202.38.160.2 255.255.255.0
#
l2tp-group 1
allow l2tp virtual-template 1 remote A8010
tunnel password simple huawei
tunnel name LNS
#
return
3.7.3 Example for Configuring Client-Initialized VPNs

This section provides an example for configuring a client-initialized VPN with clients accessing
the NAS through the PSTN.
As shown in Figure 3-4, the staff on business trip accesses the NAS through the PSTN, and
Router A on the LNS side of the company headquarters connects the NAS through the Internet.
The data generated during the communication between the staff and the LNS is transmitted
through the tunnel.
Figure 3-4 Networking diagram of client-initialized VPNs
Staff on
errands
RouterA
LNS
NAS
PSTN
Internet
Tunnel
Server
Headquarters
1.
The VPN user firstly connects the Internet, and then originates the tunnel connection request
to the LNS.
2.
A virtual tunnel is set up between the VPN user and the LNS after the LNS accepts this
connection request.
Issue 02 (2012-03-30)

235

3.
The VPN user communicates with the company headquarters by using the tunnel between
the VPN user and LNS.
4.
The VPN user accesses the network with the default domain (the domain name is "default")
and adopts the local authentication by default. The address is allocated from the address
pool. In this condition, you need to configured the address pool in the AAA view on the
LNS.
Data Preparation
l
User name and password of the VPN
IP address of the interface through which the LNS connects with the tunnel
Number, IP address, and mask of the virtual-template interface, as well as L2TP group
number
Procedure
Step 1 Configure the devices on the VPN client side.
The L2TP client software must be configured on the host of the VPN client side and users can
connect to the Internet by dialing up. Then perform the following configurations. Note that the
setting process may vary with the client software.
# Set the VPN user name as "vpdnuser", and the password as "Hello".
# Set the IP address of LNS as the IP address of the interface on the router to access the Internet.
In this example, the IP address of the interface on the LNS connected with the tunnel is
202.38.160.2.
# Modify connection attributes, and adopt the L2TP protocol.
# If the hosts on the client side support IPSec, disable IPSec.
Step 2 Configure the LNS routers.
# Create and configure a virtual-template interface.
[RouterA-Virtual-Template1] ppp authentication-mode chap
[RouterA-Virtual-Template1] remote address pool 1
# Enable L2TP and set an L2TP group.

# Configure the names of the local end and the tunnel peer on the LNS.
[RouterA-l2tp1] tunnel name LNS
[RouterA-l2tp1] allow l2tp virtual-template 1 remote vpdnuser
# Disable the tunnel authentication.

[RouterA-l2tp1] undo tunnel authentication
Issue 02 (2012-03-30)

236

# Define an address pool to assign addresses for dial-in users.

[RouterA] ip pool 1
[RouterA-ip-pool-1]network 192.168.0.0 mask 24
# Set the user name and password the same as the configurations on the VPN client side.
[RouterA] aaa
[RouterA-aaa] local-user vpdnuser password simple Hello
[RouterA-aaa] local-user vpdnuser service-type ppp
[RouterA-aaa] quit

After VPN users log in to the LAC or LNS devices, run the display l2tp tunnel command on
the LNS and you can find the tunnel is set up. For example:
[RouterA] display l2tp tunnel
Total tunnel = 1
1
1
192.168.0.2
Port
2134
Sessions RemoteName
1
vpdnuser
Run the display l2tp session command. You can find that the session is set up. For example:
[RouterA] display l2tp session
Total session = 1
LocalSID RemoteSID LocalTID
1576
1036
1
At the same time, VPN users can access the headquarters.

----End
Configuration Files
The configuration file of the LNS is as follows:
NOTE
Only the configuration files related to L2TP are listed.

#
sysname RouterA
#
l2tp enable
#
ip pool 1
network 192.168.0.0 mask 255.255.255.0
#
aaa
local-user vpdnuser password simple Hello
local-user vpdnuser service-type ppp
#
ppp authentication-mode chap
ip address 192.168.0.1 255.255.255.0
#
l2tp-group 1
undo tunnel authentication
allow l2tp virtual-template 1 remote vpdnuser
tunnel name LNS
#
return
Issue 02 (2012-03-30)

237

3.7.4 Example for Configuring LAC-Auto-Initiated VPN

This example shows how to configure LAC-auto-initiated VPN.
Departments in the enterprise headquarters need to use independent network segments. Staff in
branches need to access the networks of their own departments. To meet these requirements, an
L2TP tunnel can be established between the branch routers and router in the headquarters. As
shown in Figure 3-5, a PC in the branch connects to the LAC (RouterA) through a LAN interface,
and RouterA connects to the LNS (RouterB) through the Internet. The tunnel between RouterA
and RouterB implements communication between the branch and headquarters.
NOTE
When the AR3200 communicates with a non-Huawei device, configure the AR3200 to invert clock signals
transmitted by a synchronous serial interface as required.
Figure 3-5 Networking diagram of the LAC-auto-initiated VPN
PC
RouterB
RouterA
Serial1/0/0
12.1.1.2/24
LAN
192.168.1.0/24
Internet
Serial1/0/0
12.1.1.1/24
LNS
LAC
Tunnel
Server
headquarters
192.168.0.2/24
1.
Enable L2TP and create a virtual PPP user on the LAC. The virtual PPP user sends a
connection request to the server in the headquarters through the L2TP tunnel. After the
request is authenticated, the server assigns a private IP address to the virtual PPP user.
2.
Configure a route with the destination segment of headquarters, and outbound interface of
the virtual PPP user interface. Enable the auto-dial function on the LAC.
3.
Configure an IP address pool in the domain on the LNS.
Data Preparation
l
Number, IP address, and mask of the LAC virtual template interface
L2TP group number
Protocol used on the LNS, authentication mode (CHAP is used in this example), tunnel
password, local and remote device names of the LNS.
Number, range, and mask of the remote address pool.
Issue 02 (2012-03-30)

238

Procedure
Step 1 Configure RouterA (the LAC side).
In this example, the IP address of Serial1/0/0 on RouterA is 12.1.1.2, and the IP address of
Serial1/0/0 on RouterB is 12.1.1.1.
# Assign an IP address to Serial1/0/0 on RouterA.
# Set the user name and password, which must be the same as those on the user side.
[RouterA] aaa
[RouterA-aaa] local-user huawei password simple 123
[RouterA-aaa] local-user huawei service-type ppp
[RouterA-aaa] quit
# Configure an L2TP group and its attributes.

[RouterA-l2tp1] tunnel name LAC
[RouterA-l2tp1] start l2tp ip 12.1.1.1 fullusername huawei
# Enable tunnel authentication and set the tunnel authentication password.

[RouterA-l2tp1] tunnel password simple 123
# Configure the user name and password, authentication mode, and IP address for the virtual
PPP user.
[RouterA-Virtual-Template1] ppp pap local-user huawei password simple 123
# Configure a private route so that the packets sent to the headquarters are forwarded through
L2TP tunnels.
[RouterA] ip route-static 192.168.0.0 255.255.255.0 Virtual-Template1
# Enable RouterA to establish an L2TP tunnel.

[RouterA-virtual-template1] l2tp-auto-client enable
Step 2 Configure RouterB (the LNS side)

# Assign an IP address to Serial1/0/0 on RouterB.
[Huawei] sysname RouterB
[RouterB] interface serial 1/0/0
[RouterB-Serial1/0/0] link-protocol ppp
[RouterB-Serial1/0/0] ip address 12.1.1.1 255.255.255.0
[RouterB-Serial1/0/0] quit
# Create and configure a virtual template.

[RouterB] interface virtual-template 1
Issue 02 (2012-03-30)

239

[RouterB-Virtual-Template1]
ppp authentication-mode pap

ip address 13.1.1.1 255.255.255.0
quit
# Enable L2TP and configure an L2TP group.

[RouterB] l2tp enable
[RouterB]l2tp-group 1
# Set the local and remote device names for the LNS.
[RouterB-l2tp1] tunnel name LNS
[RouterB-l2tp1]allow l2tp virtual-template 1 remote LAC
# Enable tunnel authentication and set the tunnel password.

[RouterB-l2tp1] tunnel authentication
[RouterB-l2tp1] tunnel password simple 123
[RouterB-l2tp1] quit
# Set the user name and password, which must be the same as those on the LAC side.
[RouterB] aaa
[RouterB-aaa] local-user huawei password simple 123
[RouterB-aaa] quit
# Configure an IP address pool for assigning IP addresses to users.

[RouterB] ip pool 1
[RouterB-ip-pool-1] gateway-list 13.1.1.1
[RouterB-ip-pool-1] network 13.1.1.0 mask 255.255.255.0
[RouterB-ip-pool-1] quit

# Run the display l2tp tunnel command on the LAC and LNS to check the tunnel when a VPN
user gets online. The following shows the command output on the LNS:
[RouterB] display l2tp tunnel
Total tunnel = 1
1
1
12.1.1.1
Port
1701
Sessions RemoteName
1
LNS
# Run the display l2tp session command to check the session status. The following shows the
command output on the LNS:
[RouterB] display l2tp session
Total session = 1
LocalSID RemoteSID
1
1
LocalTID
1
# The VPN user can access the resources in the enterprise headquarters.
----End
Configuration Files
l
Configuration file of RouterA
#
sysname RouterA
#
l2tp enable
#
aaa
Issue 02 (2012-03-30)

240

domain default
local-user huawei password simple 123
local-user huawei service-type ppp
#
ppp pap local-user huawei password simple 123
ip address 13.1.1.2 255.255.255.0
l2tp-auto-client enable
#
interface Serial1/0/0
link-protocol ppp
ip address 12.1.1.2 255.255.255.0
#
l2tp-group 1
tunnel password simple 123
tunnel name LAC
start l2tp ip 12.1.1.1 fullusername huawei
#
ip route-static 192.168.0.0 255.255.255.0 Virtual-Template1
#
return
Configuration file of RouterB
#
sysname RouterB
#
l2tp enable
#
ip pool 1
gateway-list 13.1.1.1
network 13.1.1.0 mask 255.255.255.0
#
aaa
domain default
local-user huawei password simple 123
local-user huawei service-type ppp
#
ppp authentication-mode pap
ip address 13.1.1.1 255.255.255.0
#
interface Serial1/0/1
link-protocol ppp
ip address 12.1.1.1 255.255.255.0
#
l2tp-group 1
allow l2tp virtual-template 1 remote LAC
tunnel password simple 123
tunnel name LNS
#
return
Issue 02 (2012-03-30)

241

4 IPSec Configuration
IPSec Configuration
About This Chapter

IP Security (IPSec) uses data encryption and data source authentication at the IP layer to ensure
data confidentiality and integrity and prevent replay of data packets. Internet Key Exchange
(IKE) enables key negotiation and security associations (SAs) establishment to simplify use and
management of IPSec. This chapter describes how to configure IPSec and IKE.
4.1 IPSec Overview
The IP Security (IPSec) protocol family is a series of protocols defined by the Internet
Engineering Task Force (IETF). This protocol family provides high quality, interoperable, and
cryptology-based security for IP packets. Communicating parties encrypt data and authenticate
the data source at the IP layer to ensure data confidentiality and integrity and prevent replay of
data packets.
4.2 IPSec Features Supported by the AR3200
The AR3200 supports an IPSec tunnel established manually, or using IKE negotiation, IPSec
tunnel interface, or Efficient VPN policy.
4.3 Establishing an IPSec Tunnel Manually
You can establish IPSec tunnels manually when the network topology is simple.
4.4 Establishing an IPSec Tunnel Through IKE Negotiation
IKE provides an automatic protection mechanism to distribute keys, authenticate the identity,
and set up SAs on an insecure network.
4.5 Establishing an IPSec Tunnel Using an IPSec Tunnel Interface
This section describes how to create an IPSec tunnel interface and apply an IPSec profile to the
IPSec tunnel interface so that the IPSec profile configuration takes effect on the IPSec tunnel
interface.
4.6 Establishing an IPSec Tunnel Using the Efficient VPN Policy
Using an Efficient VPN policy to establish an IPSec tunnel simplifies the configuration and
reduces manual configuration workload.
4.7 Maintaining IPSec
This section describes how to display the IPSec configuration and clear the IPSec statistics.
Issue 02 (2012-03-30)

242

This section provides several configuration examples of IPSec.
Issue 02 (2012-03-30)

243

4.1 IPSec Overview

The IP Security (IPSec) protocol family is a series of protocols defined by the Internet
Engineering Task Force (IETF). This protocol family provides high quality, interoperable, and
cryptology-based security for IP packets. Communicating parties encrypt data and authenticate
the data source at the IP layer to ensure data confidentiality and integrity and prevent replay of
data packets.
IPSec uses two security protocols: Authentication Header (AH) protocol and Encapsulating
Security Payload (ESP). Key exchange and SA establishment in IPSec is implemented by the
Internet Key Exchange (IKE) protocol, which simplifies use and management of IPSec.
IPSec involves the following terms:
l
Security association (SA)

An SA is a set of conventions adopted by the communicating parties. For example, it
determines the security protocol (AH, ESP, or both), encapsulation mode (transport
mode or tunnel mode), key algorithm (DES, 3DES, or AES), shared key to protect
certain flow, and the lifetime of the shared key.
An SA is unidirectional, at least two SAs are required to protect data flows in
bidirectional communication. If two peers need to communicate using both AH and
ESP, each peer needs to establish two SAs for the two protocols.
An SA is identified by three parameters: Security Parameter Index (SPI), destination IP
address, and security protocol ID (AH or ESP).
Encapsulation mode
Transport mode: AH or ESP is inserted behind the IP header but before all transportlayer protocols, as shown in Figure 4-1.
Tunnel mode: AH or ESP is inserted before the original IP header but behind a new IP
header, as shown in Figure 4-2.
Figure 4-1 Packet format in transport mode
Mode
transport
Protocol
AH
IP Header AH TCP Header
ESP
IP Header ESP TCP Header data
AH-ESP
Issue 02 (2012-03-30)
data
ESP
Tail
ESP Auth data
IP Header AH ESP TCP Header data ESP Tail ESP Auth data

244

Figure 4-2 Packet format in tunnel mode

Mode
tunnel
Protocol
AH
ESP
new IP Header AH raw IP Header TCP Header data

new IP
Header
ESP
raw IP
Header
TCP Header dataESP Tail ESP Auth data
AH-ESP new IP Header AH ESPraw IP Header TCP Header data ESP TailESP Auth data
Authentication algorithm and encryption algorithm

IPSec uses the Message Digest 5 (MD5) algorithm, Secure Hash Algorithm (SHA-1)
or Secure Hash Algorithm (SHA-2) for authentication. The MD5 algorithm computes
faster than the SHA-1 algorithm, but the SHA-1 algorithm is more secure than the MD5
algorithm. SHA-2 increases the number of encrypted data bits and is more secure than
SHA-1.
IPSec uses the DES, Triple Data Encryption Standard (3DES), or Advanced Encryption
Standard (AES) algorithm for encryption. The ASE algorithm encrypts plain text by
using a key of 128 bits, 192 bits, or 256 bits.
Negotiation mode
IPSec uses two negotiation modes to establish SAs: manual mode (manual) and IKE
negotiation mode (isakmp).
4.2 IPSec Features Supported by the AR3200

The AR3200 supports an IPSec tunnel established manually, or using IKE negotiation, IPSec
tunnel interface, or Efficient VPN policy.
The AR3200 implements IPSec tunnel setup as follows:
l
In manual mode or IKE negotiation mode, an IPSec tunnel is established based on ACLs.
IPSec peers can use various security protection measures (authentication, encryption, or
both) on different data flows.
The general process of establishing an IPSec tunnel in manual mode or IKE negotiation
mode is as follows:
1.
Define an ACL to specify the data flows to be protected.
2.
Configure an IPSec proposal to specify the security protocol, authentication algorithm,

encryption algorithm, and encapsulation mode.
3.
Configure an IPSec policy or an IPSec policy group to specify the association between
data flows and the IPSec proposal (protection measures for the data flows), SA
negotiation mode, peer IP address (start and end points of the protection path), required
key, and SA lifetime.
4.
Apply the IPSec policy on an interface of the router.

In addition, IPSec supports MPLS VPN access. You can implement this function by:
Associating a VPN instance with an SA
Issue 02 (2012-03-30)

245

Configuring the router as a PE and associating the VPN instance with the PE
interface connected to the CE
l
An IPSec tunnel established using an IPSec tunnel interface is based on routes. If the
outbound interface in a route is the IPSec tunnel interface, IPSec protects the data flows
forwarded along the route. The IPSec configuration takes effect after the configured IPSec
profile is applied to the IPSec tunnel interface.
The general process of establishing an IPSec tunnel using tunnel interfaces is as follows:
1.
Configure an IPSec proposal to specify the security protocol, authentication algorithm,

encryption algorithm, and encapsulation mode.
2.
Configure an IKE Peer.
3.
Configure an IPSec profile and bind it to an IPSec profile to protect data flows, IKE
peer parameters, and SA lifetime.
4.
Apply the IPSec profile to the IPSec tunnel interface.
When an IPSec tunnel is established using the Efficient VPN policy, only mandatory
parameters, such as the IP address and pre-shared key, need to be configured on the remote
device. Other parameters, such as authentication and encryption algorithms used in IKE
negotiation, and the IPSec proposal, are preconfigured on the server. When the remote
device initiates IPSec tunnel negotiation, it sends its IKE capabilities including
authentication algorithm and encryption algorithm, and IPSec proposal it supports to the
server. The server establishes an IPSec tunnel with the remote device according to the
preconfigured IPSec tunnel parameters and those sent from the remote device.
NOTE
The Efficient VPN function is used with a license. To use the Efficient VPN function, apply for and purchase
the following license from the Huawei local office:
l
AR3200 Value-Added Security Package
4.3 Establishing an IPSec Tunnel Manually

You can establish IPSec tunnels manually when the network topology is simple.

Before manually establishing an IPSec tunnel, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the required data.
Data flows must be authenticated to ensure data transmission security. In a high security scenario,
data flows must be authenticated and encrypted. In such a scenario, configure IPSec on the device
that initiates the IPSec service and the device that terminates the IPSec service.
Before establishing an IPSec tunnel manually, complete the following tasks:
l
Setting parameters of the link-layer protocol for the interfaces to ensure that the link-layer
protocol on the interfaces is Up
Configuring routes between the source and the destination
Issue 02 (2012-03-30)

246

Data Preparation
To establish an IPSec tunnel manually, you need the following data.
No.
Data
Parameters of an advanced ACL
IPSec proposal name, security protocol, authentication algorithm of AH,

authentication algorithm and encryption algorithm of ESP, and packet
encapsulation mode
IPSec policy settings, including:

l Name and sequence number of the IPSec policy
l Local and peer IP addresses of the tunnel
l Inbound and outbound SPIs for AH or ESP
l Inbound and outbound authentication keys (character string or hexadecimal
number) for AH or ESP
l (optional) VPN instance name
Type and number of the interface to which the IPSec policy is applied
NOTE
Use the AH or ESP protocol based on requirements on your network.
4.3.2 Defining Protected Data Flows

IPSec can protect different data flows. In real-world applications, configure an ACL to define
the protected data flows and apply the ACL to a security policy.
Procedure
Step 1 Run:
system-view

Step 2 Run:
acl [ number ] acl-number [ match-order { config | auto } ]
An advanced ACL is created and the ACL view is displayed.

Step 3 Run:
rule
An ACL rule is configured.

NOTE
l The ACL must be configured to match the data flows accurately. It is recommended that you set the
action of the ACL rule to permit for the data flows that need to be protected.
l Create different ACLs and IPSec policies for the data flows with different security requirements.
----End
Issue 02 (2012-03-30)

247

4.3.3 Configuring an IPSec Proposal

An IPSec proposal defines the security protocol, authentication algorithm, encryption algorithm,
and packet encapsulation mode. Both ends of a tunnel must use the same IPSec proposal
configuration.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec proposal proposal-name
An IPSec proposal is created and the IPSec proposal view is displayed.

transform { ah | esp | ah-esp }
The security protocol is specified.

By default, the ESP protocol defined in RFC 2406 is used.
ah authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 }
The authentication algorithm used by AH is specified.

By default, AH uses the MD5 authentication algorithm.
esp authentication-algorithm [ md5 | sha1 | sha2-256 | sha2-384 | sha2-512 ]
The authentication algorithm used by ESP is specified.

By default, both ESP and AH use the MD5 authentication algorithm.
You can configure the authentication and encryption algorithms only after selecting a security
protocol using the transform command.
esp encryption-algorithm [ 3des | des | aes-128 | aes-192 | aes-256 ]
The encryption algorithm used by ESP is specified.

By default, ESP uses the DES encryption algorithm.
encapsulation-mode { transport | tunnel }
The packet encapsulation mode is configured.

By default, the tunnel mode is used.
----End
4.3.4 Configuring an IPSec Policy

After establishing an IPSec tunnel manually, configure an IPSec policy for the tunnel.
Issue 02 (2012-03-30)

248

Context
CAUTION
When configuring SPI, string authentication key (string-key), hexadecimal authentication key
(authentication-hex), and hexadecimal encryption key (encryption-hex) on two ends of an
IPSec tunnel, ensure that the inbound parameters on the local end are the same as the outbound
parameters on the remote end, and the outbound parameters on the local end are the same as the
inbound parameters on the remote end.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec policy policy-name seq-number manual
An IPSec policy is created.

An IPSec policy group can contain up to 10000 IPSec policies. By default, no IPSec policy
exists.
Step 3 Run:
security acl acl-number
An ACL is applied to the IPSec policy.

An IPSec policy can use only one ACL. If more than one ACL is applied to the IPSec policy,
the last configured ACL takes effect.
Step 4 Run:
proposal proposal-name
An IPSec proposal is applied to the IPSec policy.

If the manual mode is used, an IPSec policy can use only one proposal. If an IPSec proposal has
been applied to the IPSec policy, cancel the existing proposal before applying a new one to the
IPSec policy. In addition, the IPSec proposals applied on the two ends of a tunnel must have the
same security protocol, algorithm, and packet encapsulation mode.
Step 5 Run:
tunnel local ip-address
The IP address of the local end is configured.

Step 6 Run:
tunnel remote ip-address
The IP address of the remote end is configured.

Step 7 Run:
sa spi inbound { ah | esp } spi-number
The SPI of the inbound SA is configured.

Issue 02 (2012-03-30)

249

NOTE
The security protocol must be the same as the security protocol specified in the transform command in
4.3.3 Configuring an IPSec Proposal. If the security protocol specified in transform is ah-esp, both the
ah and esp protocols must be configured in the sa spi command.
Step 8 Run:
sa spi outbound { ah | esp } spi-number
The SPI of the outbound SA is configured.

NOTE
l When configuring an SA, set both inbound and outbound parameters.

l The SA parameters on two ends of a tunnel must match each other. The inbound SPI of the local end must
be the same as the outbound SPI of the remote end, and the outbound SPI of the local end must be the same
as the inbound SPI of the remote end.
Step 9 Run:
sa authentication-hex { inbound | outbound } { ah | esp } hex-key
The authentication key (a hexadecimal number) of the security protocol is configured.

Step 10 Run:
sa string-key { inbound | outbound } { ah | esp } string-key
The authentication key (a character string) of the security protocol is configured.
CAUTION
Use the same key format on the two ends. 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.
If you configure the keys in different formats, the last configured key takes effect.
Step 11 Run:
sa encryption-hex { inbound | outbound } esp hex-key
The encryption key (a hexadecimal number) is configured for ESP.

NOTE
l If the AH protocol is specified, run either the sa authentication-hex or sa string-key command.

l If the ESP protocol is specified, run one of the sa authentication-hex, sa string-key, and sa
encryption-hex commands.
l To manually create an IPSec tunnel, use the sa spi command together with the sa authenticationhex, sa string-key, or sa encryption-hex command.

sa binding vpn-instance vpn-instance-name
A VPN instance is associated with the SA.

----End
4.3.5 Applying an IPSec Policy to an Interface

A manually configured IPSec policy can be applied to only one interface.
Issue 02 (2012-03-30)

250

Context
An interface can use only one IPSec policy. An IPSec policy group that establishes an SA through
IKE negotiation can be applied to multiple interfaces, whereas an IPSec policy group that is used
to establish an SA manually can be applied only to one interface. If the applied IPSec policy
establishes an SA in manual mode, the SA is generated immediately.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The interface view is displayed.

Step 3 Run:
ipsec policy policy-name
An IPSec policy is applied to the interface.

----End

After an IPSec tunnel is manually established, you can check information about the SA, IPSec
proposal, and IPSec policy.
Prerequisites
The configurations required for establishing an IPSec tunnel manually are complete.
Procedure
l
Run the display ipsec sa command to view information about the SA.
Run the display ipsec proposal [ name proposal-name ] command to view information
about the IPSec proposal.
Run the display ipsec policy [ brief | name policy-name [ seq-number ] ] command to view
information about the IPSec policy.
----End
4.4 Establishing an IPSec Tunnel Through IKE Negotiation

IKE provides an automatic protection mechanism to distribute keys, authenticate the identity,
and set up SAs on an insecure network.

Before establishing an IPSec tunnel through IKE negotiation, familiarize yourself with the
applicable environment, complete the pre-configuration tasks, and obtain the required data.
Issue 02 (2012-03-30)

251

Application Environment
Data flows must be authenticated to ensure data transmission security. In a high security scenario,
data flows must be authenticated and encrypted. In such a scenario, configure IPSec on the device
that initiates the IPSec service and the device that terminates the IPSec service.
When the network topology is complex, you can establish IPSec tunnels through IKE
negotiation.
Before establishing an IPSec tunnel through IKE negotiation, complete the following tasks:
l
Setting parameters of the link-layer protocol and IP addresses for the interfaces to ensure
that the link-layer protocol on the interfaces is Up
Data Preparation
To establish an IPSec tunnel through IKE negotiation, you need to the following data.
No.
Data
Priority of the IKE proposal, encryption algorithm, authentication algorithm, and

authentication method used in IKE negotiation, identifier of the Diffie-Hellman
group, and SA lifetime
IKE peer name, negotiation mode, IKE proposal name, IKE peer ID type, preshared key, remote address, and remote host name

authentication algorithm and encryption algorithm of ESP, and packet
encapsulation mode
Name and sequence number of the IPSec policy, (optional) Perfect Forward
Secrecy (PFS) feature used in IKE negotiation
(Optional) Name of the IPSec policy template
(Optional) Local address of the IPSec policy group, time-based global SA

lifetime, traffic-based global SA lifetime, interval for sending keepalive packets,
timeout inertial of keepalive packets, and interval for sending NAT update packets
Type and number of the interface to which the IPSec policy is applied
NOTE
Use the AH or ESP protocol based on requirements on your network.
4.4.2 Defining Protected Data Flows

IPSec can protect different data flows. In real-world applications, configure an ACL to define
the protected data flows and apply the ACL to a security policy.
Issue 02 (2012-03-30)

252

Procedure
Step 1 Run:
system-view

Step 2 Run:
acl [ number ] acl-number [ match-order { config | auto }]

Step 3 Run:
rule
An ACL rule is configured.

NOTE
l The ACL must be configured to match the data flows accurately. It is recommended that you set the
action of the ACL rule to permit for the data flows that need to be protected.
l Create different ACLs and IPSec policies for the data flows with different security requirements.
----End
4.4.3 (Optional) Configuring an IKE Proposal

You can create multiple IKE proposals with different priority levels. The two ends must have
at least one matching IKE proposal for IKE negotiation.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ike proposal proposal-number
An IKE proposal is created and the IKE proposal view is displayed.

The IKE negotiation succeeds only when the two ends use the IKE proposals with the same
settings.
encryption-algorithm { des-cbc |3des-cbc | aes-cbc-128 | aes-cbc-192 | aescbc-256 }
The encryption algorithm is configured.

By default, an IKE proposal uses the DES-CBC encryption algorithm.
authentication-method { pre-share | rsa-signature }
The authentication method used by an IKE proposal is configured.

By default, an IKE proposal uses pre-shared key authentication.
Issue 02 (2012-03-30)

253


authentication-algorithm { md5 | sha1 | aes_xcbc_mac_96 }
The authentication algorithm is configured.

By default, an IKE proposal uses the SHA-1 algorithm.
dh { group1 | group2 | group5 | group14 }
The Diffie-Hellman group is specified.

prf { hmac-md5 | hmac-sha1 | aes_xcbc_128 }
The algorithm used to generate the pseudo random number is specified.

sa duration interval
The SA lifetime is set.

If the lifetime expires, the IKE SA is automatically updated.
You can set the lifetime only for the SAs established through IKE negotiation. The lifetime of
manually created SAs is not limited. That is, the manually created SAs are always effective.
----End
4.4.4 Configuring an IKE Peer

Procedure
Step 1 Run:
system-view

Step 2 Run:
ike peer peer-name [ v1 | v2 ]
An IKE peer is created and the IKE peer view is displayed.

exchange-mode { main | aggressive }
The IKE negotiation mode is configured.

In aggressive mode, the local ID type must be set to ip or name in step 5. In main mode, the
local ID type must be set to ip.
If the IKE peer uses IKEv2, skip this step.
ike-proposal proposal-number
An IKE proposal is configured.

local-id-type { ip | name }
Issue 02 (2012-03-30)

254

The local ID type is configured.

By default, the IP address of the local end is used as the local ID.
local-address address

By default, the local end address is the IP address of the interface bound to the IPSec policy.
peer-id-type { ip | name }
The peer ID type is configured.

By default, the IP address of the local end is used as the local ID.
The peer-id-type command is valid only when IKEv2 is used.
nat traversal
NAT traversal is enabled.

When NAT traversal is enabled, local-id-type must be set to name.
pre-shared-key key-string
The pre-shared key used by the local end and remote peer is configured.
If pre-shared key authentication is configured, configure a pre-shared key for each remote peer.
The two ends of an IPSec tunnel must use the same pre-shared key.
When pre-shared key authentication is configured, an authenticator must be configured.
Step 10 Run:
remote-address { ip-address | host-name }
The IP address or the domain name of the remote peer is configured.

NOTE
In the IPSec policy template mode, you do not need to run the remote-address command.

A VPN instance is associated with the SA.

By specifying the VPN instance that the remote end of the IPSec tunnel belongs to, you can
implement multi-instance IPSec connections. The configuration takes effect only on the initiator
of the IPSec tunnel. The initiator needs to obtain the outbound interface when sending packets.
This command specifies the VPN that the remote end belongs to. According to the VPN, the
tunnel initiator can obtain the outbound interface and send packets through the outbound
interface. The packets received by the remote peer contain the VPN attribute, so you do not need
to specify the VPN on the remote peer.
remote-name name
Issue 02 (2012-03-30)

255

The remote host name is configured. Perform this step only when name authentication is used
in aggressive mode.
If IKEv2 is used, set local-id-type to ip and peer-id-type to name, and configure remotename.
inband ocsp
The Online Certificate Status Protocol (OCSP) is enabled for the IKE peer.
pki realm realm-name
A public key infrastructure (PKI) domain is bound to the IKE peer.

After a PKI domain is bound to an IKE peer, the IKE peer can obtain the CA certificate and
local certificate based on the PKI domain configuration.
Step 15 Run:
quit

ike local-name local-name
The local host name used in the IKE negotiation is configured.

Perform this step when the local-id-type is set to name.
----End
4.4.5 Configuring an IPSec Proposal

Both ends of the tunnel must be configured with the same security protocol, authentication
algorithm, encryption algorithm, and packet encapsulation mode.
Procedure
Step 1 Run:
system-view

Step 2 Run:
An IPSec proposal is created and the IPSec proposal view is displayed.

transform { ah | esp | ah-esp }
The security protocol is configured.

By default, the ESP protocol defined in RFC 2406 is used.
ah authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 }
The authentication algorithm used by AH is configured.

Issue 02 (2012-03-30)

256

By default, AH uses the MD5 authentication algorithm.

esp authentication-algorithm [ md5 | sha1 | sha2-256 | sha2-384 | sha2-512 ]
The authentication algorithm used by ESP is configured.

By default, ESP uses the MD5 authentication algorithm.
esp encryption-algorithm { 3des | des | aes-128 | aes-192 | aes-256 }
The encryption algorithm used by ESP is configured.

By default, ESP uses the DES encryption algorithm.
encapsulation-mode { transport | tunnel }
The packet encapsulation mode is configured.

By default, the security protocol uses the tunnel mode to encapsulate IP packets.
----End
4.4.6 Configuring an IPSec Policy

After configuring an IKE peer, apply it to an IPSec policy. Then the two ends can start IKE
negotiation.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec policy policy-name seq-number isakmp [ template template-name ]
An IPSec policy is created.

Step 3 Run:
An IPSec proposal is applied to the IPSec policy.

An IPSec policy that uses IKE negotiation can reference a maximum of six IPSec proposals.
During IKE negotiation, the two ends of the IPSec tunnel use the IPSec proposals with the same
parameter settings first.
Step 4 Run:
An ACL is applied to the IPSec policy.

sa trigger-mode { auto | traffic-based }
The SA triggering mode is configured.

Issue 02 (2012-03-30)

257

After IKE negotiation phase 1 succeeds, the IPSec SA is established in the specified triggering
mode. In automatic triggering mode, the IPSec SA is established immediately after IKE
negotiation phase 1 succeeds. In traffic-based triggering mode, the IPSec SA is established only
after packets are received.
By default, the automatic triggering mode is used.
sa duration { traffic-based kilobytes | time-based interval }

l In IKEv1, the IKE peers compare the lifetime set in their IPSec proposals and use the smaller
value as the IPSec SA lifetime.
l In IKEv2, the IKE peers do not negotiate the SA lifetime. Instead, they use the locally set
SA lifetime.
l The default IPSec SA lifetime is 3600 seconds, and the default traffic volume is 1843200
kilobytes.
Step 7 Run:
ike-peer peer-name
An IKE peer is applied to the IPSec policy.

NOTE
For details on how to configure an IKE peer, see 4.4.4 Configuring an IKE Peer.

pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 }
The Perfect Forward Secrecy (PFS) feature used in the negotiation is configured.
If PFS is specified on the local end, you also need to specify PFS on the remote peer. The DiffieHellman group specified on the two ends must be the same; otherwise, the negotiation fails. If
the remote end uses the template mode, the Diffie-Hellman groups can be different.
----End
4.4.7 Configuring an IPSec Policy Template

An IPSec policy template can be used to configure multiple IPSec policies, reducing the
workload of establishing multiple IPSec tunnels.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec policy-template policy-template-name seq-number
An IPSec policy template is created.

Issue 02 (2012-03-30)

258

An ACL is applied to the IPSec policy template.

Step 4 Run:
An IPSec proposal is applied to the IPSec policy template.

An IPSec policy that uses IKE negotiation can reference a maximum of six IPSec proposals.
During IKE negotiation, the two ends of the IPSec tunnel use the IPSec proposals with the same
parameter settings first.
sa duration { traffic-based kilobytes | time-based interval }
The IPSec SA lifetime is set.

Step 6 Run:
ike-peer peer-name
An IKE peer is applied to the IPSec policy template.

The Perfect Forward Secrecy (PFS) feature used in the negotiation is configured.
By default, the PFS feature is not used in IKE negotiation.
----End
4.4.8 (Optional) Setting Optional Parameters

This section describes how to set optional parameters for IKE negotiation.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec sa global-duration { time-based interval | traffic-based kilobytes }
The global SA lifetime is set.

You can set the lifetime only for the SAs established through IKE negotiation. The lifetime of
manually created SAs is not limited. That is, the manually created SAs are always effective.
If the SA lifetime is not set in an IPSec policy, the global lifetime is used.
The new global lifetime does not affect the IPSec policies that have their own lifetime or the
SAs that have been established. The new global lifetime will be used to establish new SAs during
IKE negotiation.
Step 3 Run:
ike heartbeat-timer interval interval
The interval for sending heartbeat packets is set.

Issue 02 (2012-03-30)

259

Step 4 Run:
ike heartbeat-timer timeout interval
The timeout interval of heartbeat packets is set.

If the interval for sending heartbeat packets is set on one end, the timeout interval of heartbeat
packets must be set on the other end.
On a network, packet loss rarely occurs consecutively more than three times. Therefore, the
timeout interval of heartbeat packets on one end can be set to three times the interval for sending
heartbeat packets on the other end.
Step 5 Run:
ike nat-keepalive-timer interval interval
The interval for sending NAT keepalive packets is set.

Step 6 Run:
ipsec anti-replay { enable | disable }
The anti-replay function is set.

Step 7 Run:
ipsec df-bit { clear | set | copy }
The DF flag bit is set on the IPSec tunnel.

Step 8 Run:
ipsec fragmentation before-encryption
The fragmentation mode of IPSec packets is set.

Step 9 Run:
ike peer
The IKE peer view is displayed.

Step 10 Run:

Step 11 Run following commands to configure the dead peer detection (DPD) function.
l
Run:
dpd { idle-time seconds | retransmit-interval seconds | retry-limit times }
The idle time for DPD, retransmission interval of DPD packets, and maximum number of
retransmissions are set.
l
Run:
dpd msg { seq-hash-notify | seq-notify-hash }
The sequence of payload in DPD packets is configured.

l
Run:
dpd type { on-demand | periodic }
The DPD mode is configured.

----End
Issue 02 (2012-03-30)

260

4.4.9 (Optional) Configuring Route Injection

Route injection associates route selection with the IPSec tunnel status. If the IPSec tunnel is Up,
the route of the IPSec peer can be added and advertised. If the IPSec tunnel is Down, the route
of the IPSec peer can be deleted and withdrawn.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec policy policy-name seq-number isakmp
The IPSec policy view is displayed.

The IPSec policy must be configured using IKE negotiation or an IPSec tunnel interface.
Step 3 Run:
route inject { static | dynamic } [ preference preference ]
Route injection is enabled.

By default, route injection is disabled.
----End
4.4.10 Applying an IPSec policy to an interface

An interface can use only one IPSec policy. An IPSec policy for IKE negotiation can be applied
to multiple interfaces.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:

Only one IPSec policy can be applied to an interface. An IPSec policy can be applied to multiple
interfaces.
After the configuration is complete, the packets transmitted between two ends of the IPSec tunnel
trigger SA establishment through IKE negotiation. In automatic triggering mode, the SA is
established immediately after the IKE negotiation succeeds. In traffic-based triggering mode,
the SA is established only after data flows matching the IPSec policy are sent from the interface.
Issue 02 (2012-03-30)

261

After IKE negotiation succeeds and the SA is established, the data flows are encrypted and then
transmitted between two ends.
----End

After an IPSec tunnel is established through IKE negotiation, you can view information about
the SA, configuration of the IKE peer, and configuration of the IKE proposal.
Prerequisites
The configurations required to establish an IPSec tunnel through IKE negotiation are complete.
Procedure
l
Run the display ike sa [ v2 ] [ conn-id connid | peer-name peername | phase phasenumber | verbose ] command to view information about the SAs established through IKE
negotiation.
Run the display ike peer [ name peer-name ] [ verbose ] command to view the
configuration of a specified IKE peer or all IKE peers.
Run the display ike proposal command to view the configuration of a specified IKE
proposal or all IKE proposals.
Run the display ipsec sa [ brief | duration | policy policy-name [ seq-number ] | peerip
peer-ip-address ] command to view the configuration of a specified SA or all SAs.
Run the display ipsec policy [ brief | name policy-name [ seq-number ] ] command to view
information about a specified IPSec policy or all IPSec policies.
Run the display ipsec proposal [ name proposal-name ] command to view information
about a specified IPSec proposal or all IPSec proposals.
----End
4.5 Establishing an IPSec Tunnel Using an IPSec Tunnel

Interface
This section describes how to create an IPSec tunnel interface and apply an IPSec profile to the
IPSec tunnel interface so that the IPSec profile configuration takes effect on the IPSec tunnel
interface.

Before establishing an IPSec tunnel using an IPSec tunnel interface, familiarize yourself with
the applicable environment, complete the pre-configuration tasks, and obtain the data required
for configuration. This will help you complete the configuration task quickly and accurately.
An IPSec profile simplifies IPSec policy management. After an IPSec profile is applied to an
IPSec tunnel interface, only one IPSec tunnel is generated and this tunnel protects all the data
flows passing through the IPSec tunnel interface.
Issue 02 (2012-03-30)

262

Before establishing an IPSec tunnel using an IPSec tunnel interface, complete the following
tasks:
l
Setting link layer protocol parameters and IP addresses for interfaces to ensure that the link
layer protocol on the interfaces is Up
Data Preparation
To establish an IPSec tunnel using an IPSec tunnel interface, you need the following data.
No.
Data

authentication algorithm and encryption algorithm of ESP, packet encapsulation
mode, and PFS feature
IKE peer name, negotiation mode, IKE proposal name, IKE peer ID type, preshared key
SA lifetime and global SA lifetime
Number, IP address, and source and destination IP addresses of the IPSec tunnel
interface
Number of the IPSec tunnel interface to which an IPSec profile is applied
4.5.2 Configuring an IPSec Profile

An IPSec profile simplifies IPSec policy management.
Context
An IPSec profile defines the IKE peer, IPSec proposal, SA lifetime, and Perfect Forward Secrecy
(PFS). To ensure successful IKE negotiation, parameters in the IPSec profile on the local end
and remote end must match.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipsec profile profile-name
An IPSec profile is created and the IPSec profile view is displayed.

IPSec profiles can only be applied to IPSec tunnel interfaces.
Step 3 Run:
Issue 02 (2012-03-30)

263

An IPSec proposal referenced by an IPSec profile is configured.

An IPSec profile can reference a maximum of 12 IPSec proposals. By default, an IPSec profile
does not reference any IPSec proposals.
NOTE
For details on how to configure an IKE proposal, see 4.4.5 Configuring an IPSec Proposal.
Step 4 Run:
ike-peer peer-name
An IKE peer referenced by an IPSec profile is configured.

By default, an IPSec profile does not reference any IKE peers.
NOTE
For details on how to configure an IKE peer, see 4.4.4 Configuring an IKE Peer.

The Diffie-Hellman group referenced by an IPSec profile during negotiation is configured.

By default, an IPSec profile does not reference any Diffie-Hellman group during negotiation.
sa duration {
traffic-based kilobytes | time-based seconds }

Step 7 Run:
quit

ipsec sa global-duration { time-based seconds | traffic-based kilobytes }
The global SA lifetime is set.

By default, the global SA lifetime represented by time is 3600 seconds; the global SA lifetime
represented by traffic volume is 1843200 kilobytes.
----End
4.5.3 Configuring an IPSec Tunnel Interface

This section describes how to apply an IPSec profile to an IPSec tunnel interface.
Context
An IPSec tunnel interface encapsulates the IPSec header into packets. To make a configured
IPSec profile take effect, configure an IPSec tunnel interface and apply the IPSec profile to the
IPSec tunnel interface.
Issue 02 (2012-03-30)

264

Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ip address
An IPv4 address is configured for the tunnel interface.

Step 4 Run:
tunnel-protocol { gre [
p2mp ] | ipsec | ipv4-ipv6 | none }
The encapsulation mode is set for the tunnel interface.

NOTE
A tunnel interface can be bound to an IPSec profile only when the encapsulation mode of the tunnel interface
is set to IPSec, GRE, or Multipoint GRE (MGRE).
Step 5 Run:
source { [ vpn-instance vpn-instance-name ] source-ip-address | interface-type
interface-number }
The source address is configured for the tunnel interface.

NOTE
It is recommended that you specify the interface type and number for source. If you specify an IP address
that is dynamically assigned to an interface, the IPSec configuration may fail to be restored because of
invalid source address.

destination dest-ip-address
The destination address is configured for the tunnel interface.

If the encapsulation mode of a tunnel interface is set to IPSec, you only need to configure the
destination address for one IKE peer. If the encapsulation mode of a tunnel interface is set to
GRE, you need to configure destination addresses for both IKE peers.
Step 7 Run:
An IPSec profile is applied to the tunnel interface.

By default, no IPSec profile is applied to an interface.
----End

After an IPSec tunnel is established using an IPSec tunnel interface, you can view the
configuration of the IPSec profile, IPSec proposal, SA, and IPSec tunnel interface.
Issue 02 (2012-03-30)

265

Prerequisites
All the configurations of the IPSec tunnel established using an IPSec tunnel interface are
complete.
Procedure
l
Run the display ipsec profile [ brief | name profile-name ] command to check the IPSec
profile information.
Run the display ipsec proposal [ name proposal-name ] command to check the IPSec
proposal information.
Run the display ipsec sa [ brief | duration | policy policy-name [ seq-number ] | profile
profile-name | peerip peer-ip-address ] command to check the SA information.
Run the display this command in the interface view to check the configuration of the tunnel
interface.
----End
4.6 Establishing an IPSec Tunnel Using the Efficient VPN

Policy
Using an Efficient VPN policy to establish an IPSec tunnel simplifies the configuration and
reduces manual configuration workload.

Before configuring the Efficient VPN policy, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the data required for
You must perform a great number of IPSec configurations on two peers to establish an IPSec
tunnel between the peers. The configurations include the authentication and encryption
algorithms used in IKE negotiation, Diffie-Hellman key agreement protocol, and IPSec proposal.
If the network has hundreds of sites, the IPSec configurations on remote devices are complicated.
Huawei provides the Efficient VPN solution, which allows remote branches to easily connect
to the enterprise headquarters and releases enterprise administrators from complex manual
configurations.
Preconfiguration Tasks
Before configuring the Efficient VPN policy, complete the following tasks:
l
Configuring link layer protocol parameters for interfaces to ensure that the link layer
protocol status on the interfaces is Up
Data Preparation
To configure the Efficient VPN policy, you need the following data.
Issue 02 (2012-03-30)

266

No.
Data
Name and priority of the IKE proposal, encryption algorithm, authentication

algorithm, and authentication method used in IKE negotiation, identifier of the
Diffie-Hellman group, SA lifetime, and IPSec proposal name
Name and sequence number of an IPSec policy, and name and sequence number
of an IPSec policy template
DNS server address, WINS server address, and allocable network segment
address in the global address pool
IKE local address, IKE peer address, and peer name
4.6.2 Configuring Client Mode

The client mode of the Efficient VPN policy protects data flows whose addresses are NAT
translated.
Context
Only mandatory parameters, such as the 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 server.
Procedure
Step 1 Perform the following steps on the remote router:
1.
Run:
system-view

2.
Run:
ipsec efficient-vpn efficient-vpn-name mode client
An IPSec Efficient VPN policy in client mode is created and the Efficient VPN policy view
is displayed.
3.
Run:
remote-address { ip-address | host-name } { v1 | v2 }
An IP address or domain name is configured for the remote IKE peer.

4.
(Optional) Run:
remote-name name
A name is specified for the remote IKE peer.

5.
(Optional) Run:
authentication-method { pre-share |
rsa-signature }
An authentication method is specified for the IKE proposal.

Issue 02 (2012-03-30)

267

6.
(Optional) Run:
pre-shared-key key
An authenticator is configured for pre-shared key authentication.

7.
Run:
quit

8.
Run:

9.
Run:
ipsec efficient-vpn(interface view) efficient-vpn-name
The Efficient VPN policy is applied to the interface.

Step 2 Perform the following steps on the server router:
1.
Run:
system-view

2.
Run:
ip pool ip-pool-name
A global address pool is created.

3.
Run:
network ip-address [ mask { mask | mask-length } ]
An allocable network segment address is specified for the global address pool.
4.
Run:
quit

5.
Run:
aaa

6.
Run:
service-scheme service-scheme-name
A service scheme is created and the service scheme view is displayed.

7.
(Optional) Run:
dns ip-address
The IP address of the primary DNS server is specified.

8.
(Optional) Run:
dns ip-address secondary
The IP address of the secondary DNS server is specified.

9.
Run:
ip-pool pool-name [ move-to new-position ]
The location of the IP address pool is specified in the AAA service scheme.
Issue 02 (2012-03-30)

268

10. (Optional) Run:

wins ip-address
The IP address of the primary WINS server is specified.

11. (Optional) Run:
wins ip-address secondary
The IP address of the secondary WINS server is specified.

12. Run:
quit

13. Run:
quit

14. Run:
ike-proposal proposal-number
An IKE proposal is configured.

For details, see 4.4.3 (Optional) Configuring an IKE Proposal.
NOTE
The DH group used in IKE negotiation must be set to dh group2 for an efficient-vpn policy.
15. Run:
quit

16. Run:
ike peer peer-name { v1 | v2 }
An IKE peer is configured.

For details, see 4.4.4 Configuring an IKE Peer.
NOTE
l When the IKE v1 version is used, the aggressive mode must be enabled using exchange-mode.
l Run the service-scheme command to bind the IKE peer to the AAA service scheme.
17. Run:
quit

18. Run:
An IPSec proposal is configured.

For details, see 4.4.5 Configuring an IPSec Proposal.
NOTE
l encapsulation-mode must be set to tunnel to establish an IPSec tunnel using the Efficient VPN policy.
l The Efficient VPN policy supports only Encapsulating Security Payload (ESP).
19. Run:
Issue 02 (2012-03-30)

269

quit

20. Run:
ipsec policy-template template-name seq-number
An IPSec policy template is created.

For details, see 4.4.7 Configuring an IPSec Policy Template.
21. Run:
quit

22. Run:
ipsec policy policy-name seq-number isakmp template template-name
An SA is created using the configured IPSec policy template.

For details, see 4.4.6 Configuring an IPSec Policy.
23. Run:
quit

24. Run:

25. Run:

----End
4.6.3 Configuring Network Mode

The network mode of the Efficient VPN policy protects data flows that match ACLs.
Context
Perform the following steps on the routers on the remote device and server:
Procedure
Step 1 Run:
system-view

Step 2 Run:
acl [ number ] acl-number [ match-order { config | auto } ]

Step 3 Run:
rule
Issue 02 (2012-03-30)

270

The ACL rule is configured in the ACL view.

NOTE
Afer the ACL is applied, the ACL rules can match only IP packets.
Step 4 Run:
quit

Step 5 Run:
ipsec efficient-vpn efficient-vpn-name mode network
An IPSec Efficient VPN policy in network mode is created and the Efficient VPN view is
displayed.
Step 6 Run:
An ACL rule is used.

Step 7 Run:
remote-address { ip-address | host-name } { v1 | v2 }
An IP address or domain name is configured for the remote IKE peer.

remote-name name
The name of the remote IKE peer is specified.

authentication-method { pre-share |
rsa-signature }
An authentication method is specified for the IKE proposal.

By default, an IKE proposal uses pre-shared key authentication.
pre-shared-key key
The key is specified for pre-shared key authentication.

By default, no key is specified for pre-shared key authentication.
The perfect forward secrecy (PFS) features is used in IKE negotiation.

pki realm realm-name
A PKI domain is specified.

A VPN instance is specified to bind the IPSec tunnel.

Issue 02 (2012-03-30)

271

NOTE
Before executing this command, configure the VPN instance.

local-id-type { ip | name }
The type of IKE ID is set.

By default, the IKE ID is in format of the IP address.
An IP address is configured for the local end of IKE negotiation.

Step 16 Run:
quit

aaa

service-scheme service-scheme-name
A service scheme is created and the service scheme view is displayed.

dns ip-address
The IP address of the primary DNS server is configured.

dns ip-address secondary
The IP address of the secondary DNS server is configured.

wins ip-address
The IP address of the primary WINS server is configured.

wins ip-address secondary
The IP address of the secondary WINS server is configured.

quit

quit

Step 25 Run:
Issue 02 (2012-03-30)

272


Step 26 Run:
ipsec efficient-vpn efficient-vpn-name
The Efficient VPN policy is applied to the interface.

----End
4.6.4 Verifying the Configuration

After completing Efficient VPN configuration, you can view information about the IPSec
proposal, SA, IPSec Efficient VPN policy, and IPSec tunnel established using the Efficient VPN
policy.
Prerequisites
All Efficient VPN configurations are complete.
Procedure
l
Run the display ike sa [ v2 ] [ conn-id connid | peer-name peername | phase phasenumber | verbose ] command to check information about the IPSec tunnel established
through IKE negotiation.
profile-name | efficient-vpn efficient-vpn-name | peerip peer-ip-address ] command to
check information about SAs.
Run the display ipsec proposal [ name proposal-name ] command to check information
about IPSec proposals.
Run the display ipsec efficient-vpn [ brief | capality | name efficient-vpn-name ] command
to check information about the Efficient VPN policy.
----End
4.7 Maintaining IPSec

This section describes how to display the IPSec configuration and clear the IPSec statistics.
4.7.1 Displaying the IPSec Configuration

You can run the following display commands to view information about the SA, established
IPSec tunnel, and statistics about IPSec packets.
Prerequisites
The configurations of IPSec are complete.
Procedure
l
Issue 02 (2012-03-30)
profile-name | peerip peer-ip-address ] command to check information about the IPSec
SA.
273

Run the display ike sa [ v2 ] [ conn-id connid | peer-name peername | phase phasenumber | verbose ] command to check information about the IPSec tunnel that is
established.
Run the display ipsec statistics { ah | esp } command to check the statistics about IPSec
packets.
Run the display ike statistics { all | msg | v1 | v2 } command to check the statistics about
IKE packets.
Run the display ipsec profile [ brief | name profile-name ] command to check information
about the IPSec profile.
Run the display ipsec efficient-vpn [ brief | capality | name efficient-vpn-name ] command
to check information about the Efficient VPN policy.
----End
4.7.2 Clearing IPSec Information

This section describes how to clear the statistics about IPSec and IKE packets, information about
SAs, and information about the IPSec tunnels established through IKE negotiation.
Context
CAUTION
The statistics cannot be restored after being cleared.
Procedure
l
Run the reset ipsec statistics { ah | esp } command in the user view to clear the statistics
about IPSec packets.
Run the reset ike statistics { all | msg } command in the user view to clear the statistics
about IKE packets.
Run the reset ipsec sa [ remote ip-address | policy policy-name [ seq-number ] |

parameters dest-address { ah | esp } spi ] command in the user view to clear an SA.
Run the reset ipsec sa profile profile-name command in the user view to clear the SA
generated by the IPSec profile.
Run the reset ipsec sa efficient-vpn efficient-vpn-name command in the user view to clear
the SA generated by the Efficient VPN policy.
Run the reset ike sa { all | conn-id connection-id } command in the user view to delete a
specified IPSec tunnel or all established IPSec tunnels.
----End

This section provides several configuration examples of IPSec.
Issue 02 (2012-03-30)

274

4.8.1 Example for Establishing an SA Manually

You can establish security associations (SAs) manually when the network topology is simple.
When there are a large number of devices on the network, it is difficult to establish SAs manually,
and network security cannot be ensured.
As shown in Figure 4-3, an IPSec tunnel is established between RouterA and RouterB to protect
data flows between the subnet of PC A (10.1.1.0/24) and subnet of PC B (10.1.2.0/24). The
IPSec tunnel uses the ESP protocol, DES encryption algorithm, and SHA-1 authentication
algorithm.
Figure 4-3 Network diagram for configuring IPSec
Eth 1/0/0
Eth 1/0/0
202.138.163.1/24
RouterA
202.138.162.1/24
RouterB
Internet
IPSec Tunnel
PC A
10.1.1.2/24
10.1.2.2/24
PC B
1.
Configure IP addresses for interfaces.
2.
Configure Access Control Lists (ACLs) and define the data flows to be protected.
3.
Configure static routes to peers.
4.
Configure an IPSec proposal.
5.
Configure IPSec policies and apply the ACLs and IPSec proposal to the IPSec policies.
6.
Apply IPSec policies to interfaces.
Procedure
Step 1 Configure IP addresses for the interfaces on RouterA and RouterB.
# Assign an IP address to the interface of RouterA.
[Huawei] interface ethernet 1/0/0
[Huawei-Ethernet1/0/0] ip address 202.138.163.1 255.255.255.0
[Huawei-Ethernet1/0/0] quit
Issue 02 (2012-03-30)

275

# Assign an IP address to the interface of RouterB.

Step 2 Configure ACLs on RouterA and RouterB to define the data flows to be protected.
# Configure an ACL on RouterA.
[Huawei] acl number 3101
[Huawei-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0
0.0.0.255
[Huawei-acl-adv-3101] quit
# Configure an ACL on RouterB.

0.0.0.255
Step 3 Configure static routes to the peers on RouterA and RouterB.

# Configure a static route to the peer on RouterA. In this example, the next hop to PCB is
202.138.163.2.
[Huawei] ip route-static 10.1.2.0 255.255.255.0 202.138.163.2
# Configure a static route to the peer on RouterB. In this example, the next hop to PCA is
202.138.162.2.
Step 4 Create an IPSec proposal on RouterA and RouterB.

# Create the IPSec proposal on RouterA.
[Huawei] ipsec proposal tran1
[Huawei-ipsec-proposal-tran1] esp authentication-algorithm sha1
[Huawei-ipsec-proposal-tran1] quit
# Create the IPSec proposal on RouterB.

[Huawei-ipsec-proposal-tran1] esp authentication-algorithm sha1
Run the display ipsec proposal command on RouterA and RouterB to view the configuration
of the IPSec proposal. Take the display on RouterA as an example.
[Huawei] display ipsec proposal
Number of Proposals: 1
IPsec proposal name: tran1
Encapsulation mode: Tunnel
Transform
: esp-new
ESP protocol
: Authentication SHA1-HMAC-96
Encryption
DES
Step 5 Create IPSec policies on RouterA and RouterB.

# Create an IPSec policy on RouterA.
[Huawei] ipsec policy map1 10 manual
[Huawei-ipsec-policy-manual-map1-10] security acl 3101
[Huawei-ipsec-policy-manual-map1-10] proposal tran1
Issue 02 (2012-03-30)

276

[Huawei-ipsec-policy-manual-map1-10]
tunnel remote 202.138.162.1
tunnel local 202.138.163.1
sa spi outbound esp 12345
sa spi inbound esp 54321
sa string-key outbound esp abcdefg
sa string-key inbound esp gfedcba
quit
# Create an IPSec policy on RouterB.

[Huawei] ipsec policy use1 10 manual
[Huawei-ipsec-policyl-manual-use1-10]
security acl 3101

proposal tran1
tunnel remote 202.138.163.1
tunnel local 202.138.162.1
sa spi outbound esp 54321
sa spi inbound esp 12345
sa string-key outbound esp gfedcba
sa string-key inbound esp abcdefg
quit
Run the display ipsec policy command on RouterA and RouterB to view the configurations of
the IPSec policies. Take the display on RouterA as an example.
[Huawei] display ipsec policy
===========================================
IPsec Policy Group: "map1"
Using interface: {}
===========================================
Sequence number: 10
Security data flow: 3101
Tunnel local address: 202.138.163.1
Tunnel remote address: 202.138.162.1
Proposal name:tran1
Inbound AH setting:
AH SPI:
AH string-key:
AH authentication hex key:
Inbound ESP setting:
ESP SPI: 54321 (0xd431)
ESP string-key: gfedcba
ESP encryption hex key:
ESP authentication hex key:
Outbound AH setting:
AH SPI:
AH string-key:
AH authentication hex key:
Outbound ESP setting:
ESP SPI: 12345 (0x3039)
ESP string-key: abcdefg
ESP encryption hex key:
ESP authentication hex key:
Step 6 Apply the IPSec policies to the interfaces of RouterA and RouterB.
# Apply the IPSec policy to the interface of RouterA.
[Huawei-Ethernet1/0/0] ipsec policy map1
# Apply the IPSec policy to the interface of RouterB.

[Huawei-Ethernet1/0/0] ipsec policy use1
Run the display ipsec sa command on RouterA and RouterB to view the configuration of the
IPSec SAs. Take the display on RouterA as an example.
Issue 02 (2012-03-30)

277

[Huawei] display ipsec sa

===============================
Interface: Ethernet 1/0/0
Path MTU: 1500
===============================
----------------------------IPsec policy name: "map1"
Sequence number: 10
Acl Group: 3101
Acl rule: 0
Mode: Manual
----------------------------Encapsulation mode: Tunnel
Tunnel local : 202.138.163.1
Tunnel remote: 202.138.162.1
[Outbound ESP SAs]
SPI: 12345 (0x3039)
Proposal: ESP-ENCRYPT-DES-64 ESP-AUTH-SHA1
No duration limit for this SA
[Inbound ESP SAs]
SPI: 54321 (0xd431)
Proposal: ESP-ENCRYPT-DES-64 ESP-AUTH-SHA1
No duration limit for this SA
Step 7 Verify the configurations.

After the configurations are complete, PC A can ping PC B successfully. You can run the display
ipsec statistics esp command to view packet statistics.
----End
Configuration Files
l

#
acl number
3101
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0
0.0.0.255
#
ipsec proposal
tran1
esp authentication-algorithm
sha1
#
ipsec policy map1 10
manual
security acl
3101
proposal
tran1
tunnel local
202.138.163.1
tunnel remote
202.138.162.1
sa spi inbound esp
54321
sa string-key inbound esp
gfedcba
sa spi outbound esp
12345
sa string-key outbound esp
abcdefg
#
Issue 02 (2012-03-30)

278

ip route-static 10.1.2.0 255.255.255.0

202.138.163.2
#
ip address 202.138.163.1 255.255.255.0
ipsec policy map1
#
return

#
acl number
3101
0.0.0.255
#
ipsec proposal
tran1
esp authentication-algorithm
sha1
#
ipsec policy use1 10
manual
security acl
3101
proposal tran1
tunnel local
202.138.162.1
tunnel remote
202.138.163.1
sa spi inbound esp
12345
sa string-key inbound esp
abcdefg
sa spi outbound esp
54321
sa string-key outbound esp
gfedcba
#
ip route-static 10.1.1.0 255.255.255.0
202.138.162.2
#
ip address 202.138.162.1 255.255.255.0
ipsec policy use1
#
return
4.8.2 Example for Configuring IKE Negotiation Using Default

Settings
This section provides an example for configuring IKE negotiation using default settings.
As shown in Figure 4-4, an IPSec tunnel is established between RouterA and RouterB. This
IPSec tunnel protects data flows between the subnet of PC A (10.1.1.0/24) and subnet of PC B
(10.1.2.0/24). The IPSec tunnel uses the ESP protocol, DES encryption algorithm, and MD5
authentication algorithm.
Issue 02 (2012-03-30)

279

NOTE
l In this example, the default IKE proposal is used.

l By default, a new IPSec proposal created using the ipsec proposal command uses the ESP protocol, DES
encryption algorithm, MD5 authentication algorithm, and tunnel encapsulation mode.
Figure 4-4 Network diagram for configuring IKE negotiation

Eth 1/0/0
Eth 1/0/0
202.138.163.1/24
RouterA
202.138.162.1/24
RouterB
Internet
IPSec Tunnel
PC A
10.1.1.2/24
10.1.2.2/24
PC B
1.
2.
Specify the local host ID and IKE peer for IKE negotiation.
3.
4.
5.
6.
7.
Procedure

Issue 02 (2012-03-30)

280

Step 2 Configure local IDs and IKE peers on RouterA and RouterB.
# Configure the local ID and IKE peer on RouterA.
[Huawei] ike peer spub
[Huawei-ike-peer-spub]
v1
pre-shared-key huawei
quit
NOTE
In aggressive mode, if the value of local-id-type is name, configure the IP address of the remote peer
(remote-address x.x.x.x) on the local end.
# Configure the local ID and IKE peer on RouterB.

[Huawei] ike peer spua
[Huawei-ike-peer-spua]
v1
quit
Run the display ike peer command on RouterA and RouterB to view the configuration of the
IKE peer. Take the display on RouterA as an example.
[Huawei] display ike peer name spub verbose
---------------------------------------Peer name
: spub
Exchange mode
: main on phase 1
Pre-shared-key
: huawei
Local ID type
: IP
DPD
: Disable
DPD mode
: Periodic
DPD idle time
: 30
DPD retransmit interval : 15
DPD retry limit
: 3
Host name
:
Peer Ip address
: 202.138.162.1
VPN name
:
Local IP address
:
Remote name
:
Nat-traversal
: Disable
Configured IKE version
: Version one
PKI realm
: NULL
Inband OCSP
: Disable
----------------------------------------
0.0.0.255

0.0.0.255

202.138.163.2.
Issue 02 (2012-03-30)

281

202.138.162.2.


Transform
: esp-new
ESP protocol
: Authentication MD5-HMAC-96
Encryption
DES

[Huawei] ipsec policy map1 10 isakmp
[Huawei-ipsec-policy-isakmp-map1-10]
ike-peer spub
proposal tran1
security acl 3101
quit

[Huawei] ipsec policy use1 10 isakmp
[Huawei-ipsec-policy-isakmp-use1-10]
ike-peer spua
proposal tran1
security acl 3101
quit
===========================================
IPsec policy group: "map1"
Using interface: {}
===========================================
Sequence number: 10
Peer name: spub
Perfect forward secrecy: None
Proposal name: tran1
IPsec SA local duration(time based): 3600 seconds
IPsec SA local duration(traffic based): 1843200 kilobytes
SA trigger mode: Automatic
Route inject: None
Issue 02 (2012-03-30)

282



===============================
path MTU: 1500
===============================
sequence number: 10
mode: isakmp
----------------------------Connection id: 3
tunnel local : 202.138.163.1
[inbound ESP SAs]
spi: 1406123142 (0x53cfbc86)
[outbound ESP SAs]
spi: 3835455224 (0xe49c66f8)

After the configurations are complete, PC A can ping PC B successfully. The data transmitted
between PC A and PC B is encrypted.
Run the display ike sa command on RouterA, and the following information is displayed:
[Huawei] display ike sa
Conn-ID
Peer
VPN
Flag(s)
Phase
--------------------------------------------------------14
202.138.162.1
0
RD|ST
1
16
202.138.162.1
0
RD|ST
2
Flag Description:
RD--READY
ST--STAYALIVE
RL--REPLACED
FD--FADING
TO--TIMEOUT
HRT--HEARTBEAT
BCK--BACKED UP
----End
Configuration Files
l

#
acl number
3101
0.0.0.255
#
ipsec proposal
tran1
Issue 02 (2012-03-30)

283

#
ike peer spub
v1
pre-shared-key
huawei
remote-address
202.138.162.1
#
isakmp
security acl
3101
ike-peer
spub
proposal
tran1
#
ip route-static 10.1.2.0 255.255.255.0 202.138.163.2
#
ip address 202.138.163.1 255.255.255.0
ipsec policy map1
#
return

#
acl number
3101
0.0.0.255
#
ipsec proposal
tran1
esp authentication-algorithm sha1
#
ike peer spua
v1
pre-shared-key
huawei
remote-address
202.138.163.1
#
isakmp
security acl
3101
ike-peer
spua
proposal
tran1
#
ip route-static 10.1.1.0 255.255.255.0 202.138.162.2
#
ip address 202.138.162.1 255.255.255.0
ipsec policy use1
#
return
4.8.3 Example for Configuring IKE Negotiation

IKE automatically establishes an SA and performs key exchange to improve efficiency of SA
establishment and ensure network security.
Issue 02 (2012-03-30)

284

As shown in Figure 4-5, an IPSec tunnel is established between RouterA and RouterB. This
IPSec tunnel protects data flows between the subnet of PC A (10.1.1.0/24) and subnet of PC B
(10.1.2.0/24). The IPSec tunnel uses the ESP protocol, DES encryption algorithm, and SHA-1
authentication algorithm.
Figure 4-5 Network diagram for configuring IKE negotiation
Eth 1/0/0
Eth 1/0/0
202.138.163.1/24
RouterA
202.138.162.1/24
RouterB
Internet
IPSec Tunnel
PC A
10.1.1.2/24
10.1.2.2/24
PC B
1.
2.
Configure an IKE proposal.
3.
Specify the local host ID and IKE peer for IKE negotiation.
4.
5.
6.
7.
8.
Procedure

Issue 02 (2012-03-30)

285


Step 2 Create an IKE proposal on RouterA and RouterB.

# Create the IKE proposal on RouterA.
[Huawei] ike proposal 1
[Huawei-ike-proposal-1] encryption-algorithm aes-cbc-128
[Huawei-ike-proposal-1] authentication-algorithm md5
[Huawei-ike-proposal-1] quit
# Create the IKE proposal on RouterB.

[Huawei-ike-proposal-1] encryption-algorithm aes-cbc-128
[Huawei-ike-proposal-1] authentication-algorithm md5
[Huawei] ike local-name huawei01
[Huawei] ike peer spub v1
[Huawei-ike-peer-spub] exchange-mode aggressive
[Huawei-ike-peer-spub] ike-proposal 1
[Huawei-ike-peer-spub] local-id-type name
[Huawei-ike-peer-spub] pre-shared-key huawei
[Huawei-ike-peer-spub] remote-name huawei02
[Huawei-ike-peer-spub] remote-address 202.138.162.1
[Huawei-ike-peer-spub] local-address 202.138.163.1
[Huawei-ike-peer-spub] quit
NOTE
In aggressive mode, if the value of local-id-type is name, configure the IP address of the remote peer
(remote-address x.x.x.x) on the local end.

[Huawei] ike local-name huawei02
[Huawei] ike peer spua v1
[Huawei-ike-peer-spua] exchange-mode aggressive
[Huawei-ike-peer-spua] ike-proposal 1
[Huawei-ike-peer-spua] local-id-type name
[Huawei-ike-peer-spua] pre-shared-key huawei
[Huawei-ike-peer-spua] remote-name huawei01
[Huawei-ike-peer-spua] remote-address 202.138.163.1
[Huawei-ike-peer-spua] local-address 202.138.162.1
[Huawei-ike-peer-spua] quit
---------------------------------------Peer name
: spub
Exchange mode
: aggressive on phase 1
Pre-shared-key
: huawei
Proposal
: 1
Local ID type
: Name
DPD
: Disable
DPD mode
: Periodic
DPD idle time
: 30
DPD retry limit
: 3
Host name
:
Peer Ip address
: 202.138.162.1
VPN name
:
Local IP address
: 202.138.163.1
Issue 02 (2012-03-30)

286

Remote name
: huawei02
Nat-traversal
: Disable
: Version one
Auto-configure
: Disable
PKI realm
: NULL
Inband OCSP
: Disable
----------------------------------------
0.0.0.255

0.0.0.255

202.138.163.2.
202.138.162.2.

[Huawei-ipsec-proposal-tran1]
encapsulation-mode tunnel
transform esp
esp encryption-algorithm des
quit

encapsulation-mode tunnel
transform esp
esp encryption-algorithm des
quit
Transform
: esp-new
ESP protocol
Encryption
DES
Issue 02 (2012-03-30)

287


[Huawei] ipsec policy map1 10 isakmp
ike-peer spub
proposal tran1
security acl 3101
quit

[Huawei] ipsec policy use1 10 isakmp
ike-peer spua
proposal tran1
security acl 3101
quit
===========================================
IPsec policy group: "map1"
Using interface: {}
===========================================
Sequence number: 10
Peer name: spub
Perfect forward secrecy: None
Proposal name: tran1
IPsec SA local duration(time based): 3600 seconds
IPsec SA local duration(traffic based): 1843200 kilobytes
SA trigger mode: Automatic
Route inject: None

===============================
path MTU: 1500
===============================
sequence number: 10
mode: isakmp
----------------------------Connection id: 3
tunnel local : 202.138.163.1
[inbound ESP SAs]
spi: 1406123142 (0x53cfbc86)
Issue 02 (2012-03-30)

288

proposal: ESP-ENCRYPT-DES ESP-AUTH-SHA1

[outbound ESP SAs]
spi: 3835455224 (0xe49c66f8)
proposal: ESP-ENCRYPT-DES ESP-AUTH-SHA1

After the configurations are complete, PC A can ping PC B successfully. The data transmitted
between PC A and PC B is encrypted.
Conn-ID
Peer
VPN
Flag(s)
Phase
--------------------------------------------------------14
202.138.162.1
0
RD|ST
1
16
202.138.162.1
0
RD|ST
2
Flag Description:
RD--READY
ST--STAYALIVE
RL--REPLACED
FD--FADING
TO--TIMEOUT
HRT--HEARTBEAT
BCK--BACKED UP
----End
Configuration Files
l

#
acl number
3101
0.0.0.255
#
ipsec proposal
tran1
#
ike proposal
1
encryption-algorithm aescbc-128
authentication-algorithm md5
#
ike local-name huawei01
#
ike peer spub
v1
exchange-mode
aggressive
pre-shared-key
huawei
ike-proposal
1
local-id-type
name
remote-name
huawei02
local-address
202.138.163.1
remote-address
202.138.162.1
#
Issue 02 (2012-03-30)

289

isakmp
security acl
3101
ike-peer
spub
proposal
tran1
#
ip route-static 10.1.2.0 255.255.255.0 202.138.163.2
#
ip address 202.138.163.1 255.255.255.0
ipsec policy map1
#
return

#
acl number
3101
0.0.0.255
#
ipsec proposal
tran1
#
ike proposal
1
encryption-algorithm aescbc-128
authentication-algorithm md5
#
ike local-name huawei02
#
ike peer spua
v1
exchange-mode
aggressive
pre-shared-key
huawei
ike-proposal
1
local-id-type
name
remote-name
huawei01
local-address
202.138.162.1
remote-address
202.138.163.1
#
isakmp
security acl
3101
ike-peer
spua
proposal
tran1
#
ip route-static 10.1.1.0 255.255.255.0 202.138.162.2
#
ip address 202.138.162.1 255.255.255.0
ipsec policy use1
Issue 02 (2012-03-30)

290

#
return
4.8.4 Example for Establishing an IPSec Tunnel Using an IPSec

Tunnel Interface
An IPSec tunnel can be established using an IPSec tunnel interface. This method simplifies the
IPSec configuration, reduces costs between devices on the IPSec network, and makes service
application flexible.
traffic on the IPSec tunnel interface. The IPSec tunnel uses the AH-ESP protocol, 3DES
encryption algorithm, and SHA-1 authentication algorithm.
Figure 4-6 Networking diagram for establishing an IPSec tunnel using the IPSec tunnel interface
Eth1/0/0
Eth1/0/0
202.138.163.1/24
RouterA
Tunnel0/0/0
192.168.1.1/24
10.1.1.2/24
202.138.162.1/24
Internet
RouterB
Tunnel0/0/0
192.168.1.2/24
IPSec Tunnel
10.1.2.2/24
Network A
Network B
1.
Assign IP addresses to interfaces.
2.
3.
Configure IKE proposals.
4.
Specify the local IDs and IKE peers required in IKE negotiation.
5.
Configure IPSec proposals.
6.
Configure IPSec profiles and bind the IPSec proposals and IKE peers to the IPSec profiles.
7.
Apply the IPSec profiles to the IPSec tunnel interfaces.
Procedure
Issue 02 (2012-03-30)

291



# Configure a static route to the remote peer on RouterA. This example assumes that the next
hop address in the route to RouterB is 202.138.163.2.
# Configure a static route to the remote peer on RouterB. This example assumes that the next
Step 3 Create IKE proposals on RouterA and RouterB.

# Create an IKE proposal on RouterA.
[Huawei-ike-proposal-1]
dh group5
authentication-algorithm aes_xcbc_mac_96
prf aes_xcbc_128
quit
# Create an IKE proposal on RouterB.

dh group5
prf aes_xcbc_128
quit
[Huawei] ike peer spub
v2
ike-proposal 1
quit

[Huawei] ike peer spua
v2
ike-proposal 1
quit
---------------------------------------Peer name
: spub
Pre-shared-key
: huawei
proposal
: 1
Local ID type
:
DPD
: Disable
DPD mode
: Periodic
DPD idle time
: 30
Issue 02 (2012-03-30)

292


DPD retry limit
: 3
Peer ID type
:
Host name
:
Peer IP address
:
VPN name
:
Local IP address
: 202.138.163.1
Remote name
:
Nat-traversal
: Disable
: Version two
Auto-configure
: Disable
PKI realm
: NULL
Inband OCSP
: Disable
----------------------------------------
Step 5 Create IPSec proposals on RouterA and RouterB.

# Create an IPSec proposal on RouterA.
transform ah-esp
ah authentication-algorithm sha1
esp encryption-algorithm 3des
quit
# Create an IPSec proposal on RouterB.

transform ah-esp
quit
IPSec proposal name: tran1
Transform
: ah-esp-new
AH protocol
ESP protocol
Encryption
3DES
Step 6 Create IPSec profiles on RouterA and RouterB.

# Create an IPSec profile on RouterA.
[Huawei] ipsec profile profile1
[Huawei-ipsec-profile-profile1] proposal tran1
[Huawei-ipsec-profile-profile1] ike-peer spub
[Huawei-ipsec-profile-profile1] quit
# Create an IPSec profile on RouterB.

[Huawei] ipsec profile profile2
[Huawei-ipsec-profile-profile1] proposal tran1
[Huawei-ipsec-profile-profile1] ike-peer spua
[Huawei-ipsec-profile-profile1] quit
Step 7 Apply the IPSec profiles to the interfaces of RouterA and RouterB.
# Apply the IPSec profile to the interface of RouterA.
Issue 02 (2012-03-30)

293

[Huawei-Tunnel0/0/0]
ip address 192.168.1.1 24
tunnel-protocol gre
source 202.138.163.1
ipsec profile profile1
quit
# Apply the IPSec profile to the interface of RouterB.

[Huawei-Tunnel0/0/0] ip address 192.168.1.2 24
[Huawei-Tunnel0/0/0] tunnel-protocol gre
[Huawei-Tunnel0/0/0] source 202.138.162.1
[Huawei-Tunnel0/0/0] destination 202.138.163.1
[Huawei-Tunnel0/0/0] ipsec profile profile2

Run the display ipsec profile command on RouterA and RouterB to view the configurations of
the IPSec profiles. Take the display on RouterA as an example.
[Huawei] display ipsec profile
===========================================
IPSec profile : profile1
Using interface: Tunnel0/0/0
===========================================
IPSec Profile Name
:profile1
Peer Name
:spub
PFS
Group
:0 (0:Disable 1:Group1 2:Group2 5:Group5 14:Group14)
SecondsFlag
:0 (0:Global 1:Local)
SA Life Time Seconds
:3600
KilobytesFlag
:0 (0:Global 1:Local)
SA Life Kilobytes
:1843200
Number of IPSec Proposals :1
IPSec Proposals Name
:tran1
----End
Configuration Files
l

#
ipsec proposal tran1
transform ah-esp
#
ip route-static 10.1.2.0 255.255.255.0 202.138.163.2
#
ike proposal 1
dh group5
prf aes_xcbc_128
#
ike peer spub v2
ike-proposal 1
#
ike-peer spub
proposal tran1
#
ip address 192.168.1.1 255.255.255.0
tunnel-protocol gre
Issue 02 (2012-03-30)

294

source 202.138.163.1
#
ip address 202.138.163.1 255.255.255.0
#
return

#
transform ah-esp
#
ip route-static 10.1.1.0 255.255.255.0 202.138.162.2
#
ike proposal 1
dh group5
prf aes_xcbc_128
#
ike peer spua v2
ike-proposal 1
#
ike-peer spua
proposal tran1
#
ip address 192.168.1.2 255.255.255.0
tunnel-protocol gre
source 202.138.162.1
#
ip address 202.138.162.1 255.255.255.0
#
return
4.8.5 Example for Establishing an SA Using Efficient VPN in Client

Mode
This topic describes an example for establishing an SA using Efficient VPN in client mode in
the actual networking.
data flows between the subnet of PC A (10.1.1.0/24) and subnet of PC B (10.1.2.0/24). An SA
is established and the key is exchanged automatically between the Remote and Server,
simplifying the configuration and improving efficiency.
Issue 02 (2012-03-30)

295

Figure 4-7 Networking for Establishing an SA Using Efficient VPN in Client Mode
RouterA
Remote
RouterB
Internet
Eth1/0/0
60.1.1.1/24
Server
Eth1/0/0
60.1.2.1/24
IPSec Tunnel
10.1.1.2/24
PC A
10.1.2.2/24
PC B
The configuration roadmap on RouterA is as follows:
1.
Assign an IP address to an interface.
2.
Configure a static route.
3.
Configure the Efficient VPN policy in client mode.
4.
Configure an address for the peer end in IKE negotiation.
5.
Configure a pre-shared key.
6.
Apply the Efficient VPN policy to the interface.
The configuration roadmap on RouterB is as follows:

1.
2.
3.
Configure the resource attributes to be allocated.
4.
Configure the IKE proposal and IKE peer.
5.
Configure the IPSec proposal, template policy, and policy group.
6.
Apply the policy group to the interface.
Procedure
Step 1 Configure RouterA.
1.
Assign an IP address to the interface on RouterA.

2.
Configure a static route to the remote peer on RouterA. This example assumes that the next
3.
Issue 02 (2012-03-30)
Configure the Efficient VPN policy in client mode.

296

[Huawei] ipsec efficient-vpn 2 mode client
4.
Configure an address for the peer end in IKE negotiation.

[Huawei-ipsec-efficient-vpn-2] remote-address 60.1.2.1 v2
5.
Configure a pre-shared key.

[Huawei-ipsec-efficient-vpn-2] pre-shared-key huawei
[Huawei-ipsec-efficient-vpn-2] quit
6.

[Huawei] interface ethernet1/0/0
[Huawei-Ethernet1/0/0] ipsec efficient-vpn 2
Step 2 Configure RouterB.

1.
Assign an IP address to the interface on RouterB.

2.
Configure a static route to the remote peer on RouterB. This example assumes that the next
hop address in the route to RouterA is 60.1.2.2.
3.
Configure the resource attributes to be allocated: the IP address, DNS server address, and
WINS server address.
[Huawei] ip pool pooltest
[Huawei-ip-pool-pooltest] network 100.1.1.0 mask 255.255.255.128
[Huawei-ip-pool-pooltest] quit
[Huawei] aaa
[Huawei-aaa] service-scheme schemetest
[Huawei-aaa-service-schemetest] dns 2.2.2.2
[Huawei-aaa-service-schemetest] dns 2.2.2.3 secondary
[Huawei-aaa-service-schemetest] ip-pool pooltest
[Huawei-aaa-service-schemetest] wins 3.3.3.2
[Huawei-aaa-service-schemetest] wins 3.3.3.3 secondary
[Huawei-aaa-service-schemetest] quit
[Huawei-aaa] quit
4.
Configure the IKE proposal and IKE peer.

[Huawei-ike-proposal-5] dh group2
[Huawei] ike peer rut3 v2
[Huawei-ike-peer-rut3] pre-shared-key huawei
[Huawei-ike-peer-rut3] ike-proposal 5
[Huawei-ike-peer-rut3] service-scheme schemetest
[Huawei-ike-peer-rut3] quit
5.
Configure the IPSec proposal, template policy, and policy group.

[Huawei] ipsec policy-template use1 10
[Huawei-ipsec-policy-templet-use1-10] ike-peer rut3
[Huawei-ipsec-policy-templet-use1-10] proposal tran1
[Huawei-ipsec-policy-templet-use1-10] sa duration time-based 600000
[Huawei-ipsec-policy-templet-use1-10] quit
[Huawei] ipsec policy policy1 10 isakmp template use1
6.
Apply the policy group to the interface.

[Huawei-Ethernet1/0/0] ipsec policy policy1
Step 3 Verify the configuration

1.
Issue 02 (2012-03-30)
After the preceding configuration, RouterA can still ping RouterB and the data transmitted
between them is encrypted.
297

[Huawei] display ike sa v2
Conn-ID
Peer
VPN
Flag(s)
Phase
--------------------------------------------------------64
60.1.2.1
0
RD|ST
2
62
60.1.2.1
0
RD|ST
1
Flag
Description:
RD--READY
ST--STAYALIVE
RL--REPLACED
FD--FADING
TO-TIMEOUT
HRT--HEARTBEAT
BCK--BACKED UP
2.
Run the display ipsec sa command on RouterA and RouterB to view the IPSec
configuration. The display on RouterA is used as an example.
===============================
Path MTU: 1500
===============================
----------------------------IPSec efficient-vpn name: "2"
Mode: EFFICIENTVPN-CLIENT MODE
----------------------------Connection ID
: 64
Tunnel local
: 60.1.1.1
Tunnel remote
: 60.1.2.1
Flow source
: 100.1.1.126/255.255.255.255 0/0
Flow destination : 0.0.0.0/0.0.0.0 0/0
[Outbound ESP SAs]
SPI: 3752053811 (0xdfa3cc33)
proposal: ESP-ENCRYPT-DES-64 ESP-AUTH-MD5
SA remaining key duration (bytes/sec): 1887436800/1390
Max sent sequence-number: 0
UDP encapsulation used for NAT traversal: N
[Inbound ESP SAs]
SPI: 4182141148 (0xf94668dc)
proposal: ESP-ENCRYPT-DES-64 ESP-AUTH-MD5
Max received sequence-number: 0
3.
Run the display ipsec efficient-vpn command on RouterA to view information about the
Efficient VPN policy.
[Huawei] display ipsec efficient-vpn
===========================================
IPSec efficient-vpn name: 2
Using interface
: Ethernet1/0/0
===========================================
IPSEC Efficient-vpn Name : 2
IPSEC Efficient-vpn Mode : 1 (1:Client 2:Network)
ACL Number
:
Auth Method
: 8 (8:PSK 9:RSA)
VPN name
:
Local ID Type
: 1 (1:IP 2:Name)
Remote Address
: 60.1.2.1
IKE Version
: 2 (1:IKEv1 2:IKEv2)
FQDN
:
Pre Shared Key
: huawei
PFS Type
: 0 (0:Disable 1:Group1 2:Group2 5:Group5
14:Group14)
Local Address
:
Remote Name
:
PKI Object
:
Interface loopback
: LoopBack100
Interface loopback IP
: 100.1.1.126/32
Issue 02 (2012-03-30)

298

Dns server IP
Wins server IP
: 2.2.2.2, 2.2.2.3
: 3.3.3.2, 3.3.3.3
----End
Configuration Files
l

#
ipsec efficient-vpn 2 mode client
remote-address 60.1.2.1 v2
#
ip address 60.1.1.1 255.255.255.0
ipsec efficient-vpn 2
#
ip route-static 10.1.2.0 255.255.255.0 60.1.1.2
#
return

#
#
ike proposal 5
dh
group2
#
ike peer rut3
v2
pre-shared-key
huawei
ike-proposal
5
service-scheme
schemetest
#
ipsec policy-template use1
10
ike-peer
rut3
proposal
tran1
sa duration time-based
600000
#
ipsec policy policy1 10 isakmp template
use1
#
ip pool
pooltest
network 100.1.1.0 mask
255.255.255.128
#
aaa
service-scheme
schemetest
Issue 02 (2012-03-30)

299

dns
2.2.2.2
dns 2.2.2.3
secondary
ip-pool
pooltest
wins
3.3.3.2
wins 3.3.3.3
secondary
#
interface
Ethernet1/0/0
ip address 60.1.2.1
255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0 60.1.2.2
#
return
4.8.6 Example for Establishing an SA Using Efficient VPN in

Network Mode
This topic describes an example for establishing an SA using Efficient VPN in network mode
in the actual networking.
data flows that are transmitted between the subnet of PC A (10.1.1.0/24) and subnet of PC B
(10.1.2.0/24) and match the ACL. In network mode, the remote device does not apply for or an
IP address, and NAT and PAT are disabled on the remote device.
Figure 4-8 Networking for Establishing an SA Using Efficient VPN in Network Mode
RouterA Eth1/0/0
100.1.1.1/24
Remote
Eth1/0/0.1
99.1.1.1/24
Internet
Eth1/0/0 RouterB
100.1.2.1/24
Eth1/0/0.1
99.1.2.1/24
Server
IPSec Tunnel
10.1.1.2/24
10.1.2.2/24
PC A
Issue 02 (2012-03-30)
PC B

300

The configuration roadmaps of RouterA and RouterB are as follows:
1.
2.
3.
Configure ACLs and define the data flows to be protected.
4.
Configure the Efficient VPN policy in network mode.
5.
Procedure
[Huawei] interface ethernet 1/0/0.1
[Huawei-Ethernet1/0/0.1] ip address 99.1.1.1 255.255.255.0
[Huawei-Ethernet1/0/0.1] dot1q termination vid 1
[Huawei-Ethernet1/0/0.1] arp broadcast enable
[Huawei-Ethernet1/0/0.1] quit
# Assign an IP address to the interface on RouterB.

[Huawei-Ethernet1/0/0.1] ip address 99.1.2.1 255.255.255.0
[Huawei-Ethernet1/0/0.1] dot1q termination vid 1
[Huawei-Ethernet1/0/0.1] arp broadcast enable
[Huawei-Ethernet1/0/0.1] quit

# Configure a static route to the remote peer on RouterA. This example assumes that the next
# Configure a static route to the remote peer on RouterB. This example assumes that the next
hop address in the route to RouterA is 100.1.2.2.
[Huawei-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

[Huawei-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
Issue 02 (2012-03-30)

301

Step 4 Configure the Efficient VPN policies in network mode on RouterA and RouterB.
# Configure the Efficient VPN policy in network mode on RouterA.
[Huawei] ipsec efficient-vpn easyvpn_1
[Huawei-ipsec-efficient-vpn-easyvpn_1]
mode network
pre-shared-key htipl1.,;[-09876543211;'[]
security acl 3000
quit
# Configure the Efficient VPN policy in network mode on RouterB.

[Huawei] ipsec efficient-vpn easyvpn_1
mode network
security acl 3000
quit
Step 5 Apply the Efficient VPN policies to the sub-interfaces of RouterA and RouterB.
# Apply the Efficient VPN policy to the sub-interface on RouterA.
[Huawei-Ethernet1/0/0.1] ipsec efficient-vpn easyvpn_1
# Apply the Efficient VPN policy to the sub-interface on RouterB.

[Huawei-Ethernet1/0/0.1] ipsec efficient-vpn easyvpn_1
Step 6 Verify the configuration

After the preceding configuration, RouterA can still ping RouterB and the data transmitted
between them is encrypted.
l Run the display ipsec sa command on RouterA and RouterB to view the IKE configuration.
The display on RouterA is used as an example.
Conn-ID
Peer
VPN
Flag(s)
Phase
--------------------------------------------------------3
99.1.2.1
0
RD|ST
2
2
99.1.2.1
0
RD|ST
1
Flag
Description:
RD--READY
ST--STAYALIVE
RL--REPLACED
FD--FADING
TO-TIMEOUT
HRT--HEARTBEAT
BCK--BACKED UP
l Run the display ipsec sa command on RouterA and RouterB to view the IPSec configuration.
The display on RouterA is used as an example.
===============================
Interface: Ethernet 1/0/0.1
Path MTU: 1500
===============================
----------------------------IPSec efficient-vpn name: "easyvpn_1"
mode: EFFICIENTVPN-NETWORK MODE
----------------------------Connection ID: 3
encapsulation mode: Tunnel
tunnel local
: 99.1.1.1
tunnel remote
: 99.1.2.1
Flow source
: 100.1.1.1/0.0.0.0 0/0
Flow destination : 100.1.2.1/0.0.0.0 0/0
[Outbound ESP SAs]
SPI: 71167994 (0x43deffa)
proposal: ESP-ENCRYPT-AES-256 SHA2-512-256
Issue 02 (2012-03-30)

302

Max sent sequence-number: 0

[Intbound ESP SAs]
SPI: 1488468104 (0x58b83888)
Proposal: ESP-ENCRYPT-AES-256 SHA2-512-256
Max received sequence-number: 0
----End
Configuration Files
l

#
acl number 3000
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec efficient-vpn easyvpn_1 mode network
security acl 3000
#
ip address 100.1.1.1 255.255.255.0
#
ip route-static 10.1.2.0 255.255.255.0 100.1.1.2
#
interface Ethernet1/0/0.1
dot1q termination vid 1
ip address 99.1.1.1 255.255.255.0
ipsec efficient-vpn easyvpn_1
arp broadcast enable
#
return

#
acl number 3000
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
#
ipsec efficient-vpn easyvpn_1 mode network
security acl 3000
#
ip address 100.1.2.1 255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0 100.1.2.2
#
interface Ethernet1/0/0.1
dot1q termination vid 1
ip address 99.1.2.1 255.255.255.0
ipsec efficient-vpn easyvpn_1
arp broadcast enable
#
return
Issue 02 (2012-03-30)

303

5 DSVPN Configuration
DSVPN Configuration
About This Chapter

DSVPN can be configured on the source branch, destination branch, and central office routers.
5.1 DSVPN Overview
Dynamic Smart Virtual Private Network (DSVPN) is a technology that allows branches to use
the NBMA Next Hop Resolution Protocol (NHRP) to dynamically establish data forwarding
tunnels in the hub-spoke model.
5.2 DSVPN Features Supported by the AR3200
Before implementing the DSVPN feature on the AR3200, consider routing plans and configure
Multipoint GRE (MGRE) tunnel interfaces.
5.3 Configuring DSVPN
When Dynamic Smart VPN (DSVPN) is configured, IPSec does not need to be configured. If
IPSec is configured to protect GRE traffic, the remote IP address in an NHRP mapping entry
needs to be advertised to the local device to establish an IPSec tunnel.
5.4 Maintaining DSVPN
This section describes how to display the DSVPN configuration and clear DSVPN statistics.
This section describes how to configure DSVPN when different routing plans are used.
Issue 02 (2012-03-30)

304

5.1 DSVPN Overview

Dynamic Smart Virtual Private Network (DSVPN) is a technology that allows branches to use
the NBMA Next Hop Resolution Protocol (NHRP) to dynamically establish data forwarding
tunnels in the hub-spoke model.
In the traditional hub-spoke model, data traffic concentrates at branches and the central office.
If data traffic is transmitted between two branches, to implement IP Security (IPSec), the central
office needs to decrypt data on the tunnel of the source branch and encrypt the data on the tunnel
of the destination branch. Traffic between the two branches needs to pass through the central
office, wasting resources of the central office and causing a delay in traffic forwarding. To solve
this problem, the DSVPN technology is used to enable the two branches to dynamically establish
a data forwarding tunnel.
To enable two branches to directly establish an tunnel, ensure that the next hop of the route
between the two branch subnets is a branch device. The following routing plans are available:
l
Static routes are configured on branches.

Static routes to other branch subnets are configured on the source branch so that tunnels
can be established between two branches.
Branches learn routes from each other.

Routing protocols are enabled to allow routes to be learned between branches, and between
branches and the central office. All the branches must be connected to the same logical
interface of the central office device so that routes can be advertised between branches. If
the Routing Information Protocol (RIP) is enabled, the split horizon function must be
disabled to ensure that routes are directly advertised between branches.
Branches have only summarized routes to the central office.

If branches need to learn routes from each other, they must have high-performance and
large-capacity devices. To solve this problem and enable branches to directly communicate
with each other, configure the path from a branch to the central office as the default
forwarding path and allow branches to use NHRP packets to exchange routing information.
NOTE
When DSVPN is configured, IPSec does not need to be configured. If IPSec is configured to protect GRE
traffic, the remote IP address in an NHRP mapping entry needs to be advertised to the local device to
establish an IPSec tunnel.
5.2 DSVPN Features Supported by the AR3200

Before implementing the DSVPN feature on the AR3200, consider routing plans and configure
Multipoint GRE (MGRE) tunnel interfaces.
When branches learn routes from each other or have only summarized routes to the central office,
perform the following operations to configure DSVPN:
1.
Create tunnel interfaces and specify source addresses for tunnel interfaces.
2.
Configure routes between AR3200s.
3.
Configure NHRP mapping entries of the central office device on branch devices.
Issue 02 (2012-03-30)

305

NOTE
The DSVPN function is used with a license. To use the DSVPN function, apply for and purchase the
following license from the Huawei local office:
l
AR3200 DSVPN (Dynamic Smart VPN) Function
5.3 Configuring DSVPN

When Dynamic Smart VPN (DSVPN) is configured, IPSec does not need to be configured. If
IPSec is configured to protect GRE traffic, the remote IP address in an NHRP mapping entry
needs to be advertised to the local device to establish an IPSec tunnel.

Before configuring DSVPN, familiarize yourself with the applicable environment, complete the
pre-configuration tasks, and obtain the data required for configuration. This will help you
complete the configuration task quickly and accurately.
In the traditional hub-spoke model, data traffic concentrates at branches and the central office.
If data traffic is transmitted between two branches, to implement IPSec, the central office needs
to decrypt data on the tunnel of the sending branch and encrypt the data on the tunnel of the
receiving branch. Traffic between the two branches needs to pass through the central office,
wasting resources of the central office and causing a delay in traffic forwarding. To solve this
problem, the DSVPN technology is used to enable the two branches to dynamically establish a
data forwarding tunnel.
Before configuring DSVPN, complete the following task:
l
Setting link layer parameters and IP addresses for interfaces so that the network layer
protocol of the interfaces is Up
Data Preparation
To configure DSVPN, you need the following data.
Issue 02 (2012-03-30)
No.
Data
Numbers, IP addresses, source IP addresses (or source interfaces) of tunnel

interfaces
NHRP authentication string, NHRP registration interval, and NHRP entry holding
time
(Optional) IPSec profile, IKE peer, and IKE proposal

306

5.3.2 Configuring MGRE

To configure MGRE, create a tunnel interface, and configure the tunnel encapsulation mode, IP
address, and source address for the tunnel interface.
Context
After creating a tunnel interface, set the tunnel encapsulation mode to Multipoint GRE (MGRE)
and configure a source address for the tunnel interface. To enable the tunnel interface to support
dynamic routing protocols, configure an IP address for the tunnel interface. Perform the
following operations on the routers of branches and the central office.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
tunnel-protocol gre p2mp
The tunnel encapsulation mode is set to MGRE.

NOTE
You must configure the tunnel encapsulation mode before setting the source IP address or other parameters
for a tunnel interface. Changing the encapsulation mode of a tunnel interface deletes other parameters of
the tunnel interface.
Step 4 Run:
The IP address of the tunnel interface is configured.

Step 5 Run:
source { source-ip-address | interface-type interface-number
The source address or source interface is configured for the tunnel interface.
----End
5.3.3 Configuring Tunnel Routes

To implement DSVPN, configure routes between branches.
Context
The routes passing through a tunnel must be available on branches and the central office so that
packets encapsulated with the MGRE header can be forwarded correctly. These routes can be
static routes or dynamic routes. Perform the following operations on the routers of branches and
the central office.
Issue 02 (2012-03-30)

307

Procedure
Step 1 Run:
system-view

Step 2 Choose one of the following methods to configure routes passing through a tunnel interface:
l Run:
ip route-static ip-address { mask | mask-length } tunnel interface-number
[ description text ]
A static route is configured.

NOTE
A static route must be configured on both the source and destination devices.
l Configure dynamic routes. Dynamic routing can be implemented using OSPF, RIP, or BGP.
For the configuration of a dynamic routing protocol, see Huawei AR3200 Series
Configuration Guide - IP Routing.
NOTE
l If OSPF is configured, the OSPF network type of the tunnel interface must be broadcast.
l If RIP is configured, the split horizon function must be disabled on the tunnel interface.
----End
5.3.4 Configuring NHRP on a Branch

This section describes how to configure NHRP mapping entries on a branch device.
Context
NHRP allows a source device on a Non-Broadcast Multiple Access (NBMA) network to obtain
the public address of the next hop to the destination device. Perform the following operations
on the router of a branch.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
The tunnel encryption mode is set to MGRE.

Step 4 Run:
nhrp entry protocol-address nbma-address [ register ]
An NHRP mapping entry is configured.

Issue 02 (2012-03-30)

308


nhrp authentication string
The NHRP authentication string is configured.

By default, no NHRP authentication string is configured.
nhrp registration interval seconds
The NHRP registration interval is configured.

By default, a branch device registers with the central office device at an interval of 1800 seconds.
nhrp entry holdtime seconds seconds
The holding time of NHRP entries is configured.

By default, the holding time of NHRP entries is 7200 seconds.
Step 8 Run:
nhrp shortcut
The NHRP shortcut function is enabled.

By default, the NHRP shortcut function is disabled.
NOTE
This step is required when branches have only summarized routes to the central office.
----End
5.3.5 Configuring NHRP on the Central Office

This section describes how to configure NHRP mapping entries on the central office device.
Context
NHRP allows a source device on a Non-Broadcast Multiple Access (NBMA) network to obtain
the public address of the next hop to the destination device. Perform the following operations
on the router of the central office.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
tunnel-protocol gre
p2mp
The tunnel encryption mode is set to MGRE.

Issue 02 (2012-03-30)

309


nhrp authentication string
The NHRP authentication string is configured.

By default, no NHRP authentication string is configured.
If the NHRP authentication string is configured only on a branch device but not on the central
office device, the NHRP authentication string is not used for authentication.
Step 5 Run:
nhrp entry multicast dynamic
Dynamically registered branches are added to the NHRP multicast member table.
By default, no dynamically registered branch is added to the NHRP multicast member table.
NOTE
This step is required when branches learn routes from each other.

nhrp entry holdtime seconds seconds
The holding time of NHRP mapping entries is configured.

By default, the holding time of NHRP mapping entries is 7200 seconds.
Step 7 Run:
nhrp registration no-unique
The AR3200 is configured to override conflicting NHRP mapping entries during NHRP
registration.
By default, the AR3200 does not override conflicting NHRP mapping entries during NHRP
registration.
Step 8 Run:
nhrp redirect
The NHRP redirect function is enabled.

By default, the NHRP redirect function is disabled.
NOTE
This step is required when branches have only summarized routes to the central office.
----End
5.3.6 (Optional) Configuring an IPSec Profile

An IPSec profile simplifies IPSec policy management.
Context
When DSVPN is configured, IPSec does not need to be configured. If IPSec is configured to
protect GRE traffic, the remote IP address in an NHRP mapping entry needs to be advertised to
the local device to establish an IPSec tunnel. Perform the following operations on the routers of
branches and the central office.
Issue 02 (2012-03-30)

310

Procedure
Step 1 Run:
system-view

Step 2 Run:
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.

By default, no IKE peer is bound to any IPSec profile.
NOTE
For the detailed configuration of an IKE peer, see 4.4.4 Configuring an IKE Peer.
Step 4 Run:
An IKE proposal is bound to the IPSec profile.

By default, no IKE proposal is bound to any IPSec profile.
NOTE
For the detailed configuration of an IKE proposal, see 4.4.5 Configuring an IPSec Proposal.
Step 5 Run:
The router is configured to use Perfect Forward Secrecy (PFS) in IPSec negotiation.
By default, PFS is not used in IPSec negotiation.
Step 6 Run:
quit

Step 7 Run:

Step 8 Run:
tunnel-protocol { gre [
p2mp ] | ipsec | ipv4-ipv6 | none }
The tunnel encapsulation mode is configured.

A tunnel interface can be bound to an IPSec profile only when the encapsulation mode of the
tunnel interface is set to IPSec, GRE, or Multipoint GRE (MGRE).
Step 9 Run:
Issue 02 (2012-03-30)

311

The tunnel interface is bound to an IPSec profile.

----End

After DSVPN is configured, you can view NHRP mapping entries and IPSec profile
configuration.
Prerequisites
All DSVPN configurations are complete.
Procedure
l
Run the display nhrp peer command to check NHRP mapping entries.
Run the display ipsec profile [ brief | name profile-name ] command to check the IPSec
profile configuration.
----End
5.4 Maintaining DSVPN

This section describes how to display the DSVPN configuration and clear DSVPN statistics.
5.4.1 Displaying the DSVPN Configuration

You can run the display commands to check NHRP mapping entries and NHRP packet statistics.
Prerequisites
All DSVPN configurations are complete.
Procedure
l
Run the display nhrp peer command to check NHRP mapping entries.
Run the display nhrp statistics interface interface-type interface-number command to

check NHRP packet statistics.
----End
5.4.2 Clearing DSVPN Statistics

This section describes how to clear NHRP packet statistics.
Context
CAUTION
Statistics cannot be restored after being cleared. Exercise caution when you run the reset
command.
Issue 02 (2012-03-30)

312

Procedure
l
Run the reset nhrp statistics interface interface-type interface-number command in the
user view to clear the NHRP packet statistics on a specified tunnel interface.
----End

This section describes how to configure DSVPN when different routing plans are used.
5.5.1 Example for Configuring DSVPN When Branches Learn

Routes from Each Other
This section describes how to configure DSVPN when branches learn routes from each other.
As shown in Figure 5-1, the hub (central office), Spoke1 (a branch), and Spoke2 (a branch)
belong to the same autonomous system (AS). They can communicate with each other on the IP
network using routing protocols.
Figure 5-1 Configuring DSVPN when branches learn routes from each other
Spoke1
(branch)
Eth1/0/0 44.3.1.2/24
NHRP
Tunnel 0/0/0
172.16.1.101/24
NHRP
Tunnel 0/0/0 NHRP

172.16.1.102/24
Internet
Eth1/0/0
44.1.1.1/24
Tunnel 0/0/0
172.16.1.1/24
Hub
(central office)
Eth1/0/0 44.4.1.2/24
Spoke2
(branch)
1.
Run a routing protocol on the Routers to implement interconnection.
2.
Create tunnel interfaces on the Routers (Spoke1, Spoke2, and the hub) and specify source
addresses for tunnel interfaces.
3.
Configure NHRP mapping entries of the hub on Spoke1 and Spoke2.
Issue 02 (2012-03-30)

313

Data Preparation
l
Reachable routes between the Routers
Source addresses of tunnel interfaces on the Routers
Procedure
mentioned here.
Step 2 Configure routes between the Routers.
# Configure OSPF on the Ethernet interface of the hub
[Huawei] ospf 2
[Huawei-ospf-2] area 0
[Huawei-ospf-2-area-0.0.0.0] network 44.1.1.0 0.0.0.255
[Huawei-ospf-2-area-0.0.0.0] quit
[Huawei-ospf-2] quit
# Configure OSPF on the Ethernet interface of the Spoke1

[Huawei] ospf 2
[Huawei-ospf-2-area-0.0.0.0]network 44.3.1.0 0.0.0.255
# Configure OSPF on the Ethernet interface of the Spoke2

[Huawei] ospf 2
Step 3 Configure OSPF on the tunnel interfaces.

# Configure hub
[Huawei] ospf 3
# Configure Spoke1
[Huawei] ospf 3
# Configure Spoke2
[Huawei] ospf 3
Issue 02 (2012-03-30)

314

Step 4 Configure tunnel interfaces on the Routers and configure NHRP mapping entries of the hub on
Spoke1 and Spoke2.
# Configure a tunnel interface on the hub.
[Huawei] system-view
[Huawei-Tunnel0/0/0] ip address 172.16.1.1 255.255.255.0
[Huawei-Tunnel0/0/0] tunnel-protocol gre p2mp
[Huawei-Tunnel0/0/0] source ethernet 1/0/0
[Huawei-Tunnel0/0/0] nhrp entry multicast dynamic
[Huawei-Tunnel0/0/0] ospf network-type broadcast
[Huawei-Tunnel0/0/0] ospf dr-priority 10
# Configure a tunnel interface and an NHRP mapping entry of the hub on Spoke1.
[Huawei-Tunnel0/0/0] nhrp entry 172.16.1.1 44.1.1.1 register
# Configure a tunnel interface and an NHRP mapping entry of the hub on Spoke2.

After the preceding configurations are complete, check the NHRP mapping entries on Spoke1
and Spoke2.
Run the display nhrp peer all command on Spoke1, and the command output is as follows.
[Huawei] display nhrp peer all
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.1
32
44.1.1.1
172.16.1.1
static
hub
------------------------------------------------------------------------------Tunnel interface: Tunnel0/0/0
Created time
: 2011.08.18-15:10:26
Expire time
: --
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.1
32
44.1.1.1
172.16.1.1
static
hub
Created time
: 2011.08.18-15:12:53
Expire time
: -NOTE
If you run the display nhrp peer all command on Spoke1 and Spoke2, you can view only the NHRP
mapping entry of the hub.
On the hub, check the NHRP mapping entries on Spoke1 and Spoke2.
Issue 02 (2012-03-30)

315

Run the display nhrp peer all command on the hub, and the command output is as follows.
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.101
32
44.3.1.2
172.16.1.101
dynamic
route tunnel
Created time
: 2008.01.07-18:07:45
Expire time
: 2008.01.07-20:07:52
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.102
32
44.4.1.2
172.16.1.102
dynamic
route tunnel
Created time
: 2008.01.07-18:11:51
Expire time
: 2008.01.07-20:11:57
Step 6 Run the ping command on the spoke.

If you enable Spoke1 and Spoke2 to ping each other, you can see that Spoke1 and Spoke2 have
learned NHRP mapping entries from each other.
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.1
32
44.1.1.1
172.16.1.1
static
hub
Created time
: 2011.08.18-15:10:26
Expire time
: -------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.102
32
44.4.1.2
172.16.1.102
dynamic
route tunnel
Created time
: 2011.08.18-16:09:31
Expire time
: 2011.08.18-18:09:31
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.1
32
44.1.1.1
172.16.1.1
static
hub
Created time
: 2011.08.18-15:12:53
Expire time
: -------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.101
32
44.3.1.2
172.16.1.101
dynamic
route tunnel
Created time
: 2011.08.18-16:10:33
Expire time
: 2011.08.18-18:10:33
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.102
32
44.4.1.2
172.16.1.102
dynamic
local
-------------------------------------------------------------------------------
Issue 02 (2012-03-30)

316

Tunnel interface: Tunnel0/0/0

Created time
: 2011.08.18-16:10:33
Expire time
: 2011.08.18-18:10:33
----End
Configuration Files
l
Configuration file of Spoke1

#
ip address 44.3.1.2 255.255.255.0
#
ip address 172.16.1.101 255.255.255.0
source Ethernet1/0/0
nhrp entry 172.16.1.1 44.1.1.1 register
ospf network-type broadcast
ospf dr-priority 8
#
ospf 2
area 0.0.0.0
network 44.3.1.0 0.0.0.255
#
ospf 3
area 0.0.0.0
network 172.16.1.0 0.0.0.255
#
return

#
ip address 44.4.1.2 255.255.255.0
#
ip address 172.16.1.102 255.255.255.0
ospf dr-priority 8
#
ospf 2
area 0.0.0.0
network 44.4.1.0 0.0.0.255
#
ospf 3
area 0.0.0.0
network 172.16.1.0 0.0.0.255
#
return
Configuration file of the hub

#
ip address 44.1.1.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
ospf dr-priority 10
#
ospf 2
Issue 02 (2012-03-30)

317

area 0.0.0.0
network 44.4.1.0 0.0.0.255
#
ospf 3
area 0.0.0.0
network 172.16.1.0 0.0.0.255
#
return
5.5.2 Example for Configuring DSVPN When Branches Have Only

Summarized Routes to the Central Office
This section describes how to configure DSVPN when branches have only summarized routes
to the central office.
As shown in Figure 5-2, the hub (central office), Spoke1 (a branch), and Spoke2 (a branch)
belong to the same autonomous system (AS). They can communicate with each other on the IP
network using routing protocols.
Figure 5-2 Configuring DSVPN when branches have only summarized routes to the central
office
Spoke1
(branch)
Eth1/0/0 44.3.1.2/24
NHRP
Tunnel 0/0/0
172.16.1.101/24
NHRP
Tunnel 0/0/0 NHRP

172.16.1.102/24
Internet
Eth1/0/0
44.1.1.1/24
Tunnel 0/0/0
172.16.1.1/24
Hub
(central office)
Eth1/0/0 44.4.1.2/24
Spoke2
(branch)
1.
Run a routing protocol on the Routers to implement interconnection.
2.
Create tunnel interfaces on the Routers (Spoke1, Spoke2, and the hub) and specify source
addresses for tunnel interfaces.
3.
Enable NHRP redirect on the hub and NHRP shortcut on Spoke1 and Spoke2.
4.
Configure NHRP mapping entries of the hub on Spoke1 and Spoke2.
Issue 02 (2012-03-30)

318

Data Preparation
l
Reachable routes between the Routers
Source addresses of tunnel interfaces on the Routers
Procedure
mentioned here.
Step 2 Configure routes between the Routers.
# Configure RIP on the Ethernet interface of the hub
[Huawei] rip
[Huawei-rip-1] network 44.0.0.0
[Huawei-rip-1] version 2
[Huawei-rip-1] quit
# Configure RIP on the Ethernet interface of the Spoke1

[Huawei] rip
[Huawei-rip-1] quit
# Configure RIP on the Ethernet interface of the Spoke2

[Huawei] rip
[Huawei-rip-1] quit
Step 3 Configure RIP on the tunnel interfaces.

# Configure hub
[Huawei] rip 2
[Huawei-rip-1] quit
# Configure Spoke1
[Huawei] rip 2
[Huawei-rip-1] quit
# Configure Spoke2
[Huawei] rip 2
[Huawei-rip-1] quit
Step 4 Configure tunnel interfaces on the Routers and configure NHRP mapping entries of the hub on
Spoke1 and Spoke2.
# Configure a tunnel interface and enable NHRP redirect on the hub.
Issue 02 (2012-03-30)

319

ip address 172.16.1.1 255.255.255.0
source ethernet 1/0/0
nhrp redirect
# Configure a tunnel interface and an NHRP mapping entry of the hub, and enable NHRP shortcut
on Spoke1.
[Huawei-Tunnel0/0/0] nhrp shortcut
# Configure a tunnel interface and an NHRP mapping entry of the hub, and enable NHRP shortcut
on Spoke2.
[Huawei-Tunnel0/0/0] nhrp shortcut

After the preceding configurations are complete, check the NHRP mapping entries on Spoke1
and Spoke2.
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.1
32
44.1.1.1
172.16.1.1
static
hub
Created time
: 2011.08.18-15:10:26
Expire time
: --
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.1
32
44.1.1.1
172.16.1.1
static
hub
Created time
: 2011.08.18-15:12:53
Expire time
: -NOTE
If you run the display nhrp peer all command on Spoke1 and Spoke2, you can view only the NHRP
mapping entry of the hub.
On the hub, check the NHRP mapping entries on Spoke1 and Spoke2.
Run the display nhrp peer all command on the hub, and the command output is as follows.
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.101
32
44.3.1.2
172.16.1.101
dynamic
route tunnel
Issue 02 (2012-03-30)

320


Created time
: 2008.01.07-18:07:45
Expire time
: 2008.01.07-20:07:52
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.102
32
44.4.1.2
172.16.1.102
dynamic
route tunnel
Created time
: 2008.01.07-18:11:51
Expire time
: 2008.01.07-20:11:57
Step 6 Run the ping command on the spoke.

If you enable Spoke1 and Spoke2 to ping each other, you can see that Spoke1 and Spoke2 have
learned NHRP mapping entries from each other.
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.1
32
44.1.1.1
172.16.1.1
static
hub
Created time
: 2011.08.18-15:10:26
Expire time
: -------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.102
32
44.4.1.2
172.16.1.102
dynamic
route tunnel
Created time
: 2011.08.18-16:09:31
Expire time
: 2011.08.18-18:09:31
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.1
32
44.1.1.1
172.16.1.1
static
hub
Created time
: 2011.08.18-15:12:53
Expire time
: -------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.101
32
44.3.1.2
172.16.1.101
dynamic
route tunnel
Created time
: 2011.08.18-16:10:33
Expire time
: 2011.08.18-18:10:33
------------------------------------------------------------------------------Protocol-addr
Mask NBMA-addr
NextHop-addr
Type
Flag
------------------------------------------------------------------------------172.16.1.102
32
44.4.1.2
172.16.1.102
dynamic
local
Created time
: 2011.08.18-16:10:33
Expire time
: 2011.08.18-18:10:33
----End
Issue 02 (2012-03-30)

321

Configuration Files
l

#
ip address 44.3.1.2 255.255.255.0
#
ip address 172.16.1.101 255.255.255.0
nhrp shortcut
#
rip 1
version 2
network 44.0.0.0
#
rip 2
version 2
network 172.16.1.0
#
return

#
ip address 44.4.1.2 255.255.255.0
#
ip address 172.16.1.102 255.255.255.0
nhrp shortcut
#
rip 1
version 2
network 44.0.0.0
#
rip 2
version 2
network 172.16.1.0
#
return
Configuration file of the hub

#
ip address 44.1.1.1 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
nhrp redirect
#
rip 1
version 2
network 44.0.0.0
#
rip 2
version 2
network 172.16.1.0
#
return
Issue 02 (2012-03-30)

322

6 SSL VPN Configuration
SSL VPN Configuration
About This Chapter

SSL VPN (Secure Sockets Layer VPN) is a type of secure access VPN technology. Based on
the HTTPS protocol, SSL VPN uses the data encryption, user identity authentication, and
message integrity check mechanisms of the SSL protocol to help ensure that remote access to
enterprise intranets is safe and secure.
6.1 SSL VPN Overview
The SSL VPN (Secure Sockets Layer VPN) technology allows employees, customers, and
partners to access the enterprise's intranet through the Internet anytime and anywhere.
6.2 SSL VPN Features Supported by the AR3200
The AR3200 supports the following SSL VPN features: virtual gateway, basic VPN functions,
SSL VPN user management, and SSL VPN services.
6.3 Configuring Basic SSL VPN Functions
The configurations of basic SSL VPN functions include extranet/intranet interfaces and AAA
domain.
The user management functions include configuring user information, maximum number of
online users, and maximum online duration of users, and forcibly disconnecting users.
6.5 Configuring SSL VPN Services
The AR3200 supports three service types as an SSL VPN gateway: Web proxy, port forwarding,
and IP forwarding.
This section provides several SSL VPN configuration examples.
Issue 02 (2012-03-30)

323

6.1 SSL VPN Overview

The SSL VPN (Secure Sockets Layer VPN) technology allows employees, customers, and
partners to access the enterprise's intranet through the Internet anytime and anywhere.
As the Internet technologies develop, people can access an enterprise's internal resources
whether they are at home, at work, or on the move. Enterprise employees, customers, and partners
desire access to enterprises' intranets anywhere and anytime. Unauthorized users or insecure
access hosts may threaten security of enterprises' intranets.
Secure access VPN protects enterprises' intranets against attacks and prevents data theft.
SSL VPN is a type of secure access VPN technology. Based on the HTTPS protocol, SSL VPN
uses the data encryption, user identity authentication, and message integrity check mechanisms
of the SSL protocol to help ensure that remote access to enterprise intranets is safe and secure.
SSL VPN is a remote access technology. As shown in Figure 6-1, SSL VPN meets the following
remote access requirements:
l
Dynamic remote access: Users can use any terminals to access an enterprise's intranet
through the Internet anytime and anywhere.
Differentiated user access privileges: The SSL VPN gateway assigns different access
privileges to employees, partners, and other users on the Internet. Each user can only access
authorized resources.
Terminals with different operating systems and application programs: Terminals running
different operating systems and application programs can access the enterprise's intranet.
Figure 6-1 Remote access
Home
Mobile office
SSL VPN gateway

PC
Internet
LAN
Internal servers
Partner
Hotel
Issue 02 (2012-03-30)

324

6.2 SSL VPN Features Supported by the AR3200

The AR3200 supports the following SSL VPN features: virtual gateway, basic VPN functions,
SSL VPN user management, and SSL VPN services.
Virtual Gateway
An AR3200 functioning as an SSL VPN gateway can be divided into multiple virtual gateways.
Service configuration and user management are based on virtual gateways. Before configuring
SSL VPN services on the AR3200, create a virtual gateway.
Basic SSL VPN Functions

domain.
l
When functioning as an SSL VPN gateway, the AR3200 provides two types of interfaces:
extranet interface and intranet interface.
An extranet interface connects to the Internet. Users on a virtual gateway can access the
web login page by using the extranet interface address.
An intranet interface connects to an internal server, allowing the virtual gateway to
communicate with the internal server.
To prevent unauthorized users from accessing internal resources and protect intranet
security, each virtual gateway must authenticate login users. After being bound to an AAA
domain, a virtual gateway performs AAA authentication for all login users. Only the
authenticated users are allowed to access internal resources.
To use an AR3200 as an SSL VPN gateway, you must configure and enable the basic SSL VPN
functions. If the basic SSL VPN functions are disabled, no user can access internal servers
through the SSL VPN gateway.
SSL VPN User Management

User management functions include:
l
Configuring user information

To log in to virtual gateways, each authorized user needs a user name and a password. All
the user names and passwords of the locally authenticated users are stored on virtual
gateways. After a user enters the user name and password, the virtual gateway checks
whether they are identical with the locally stored user name and password of this user. If
they are identical, the virtual gateway allows the user to log in.
Configuring the maximum number of online users

An administrator can limit the number of online users. When the number of online users
on the virtual gateway exceeds the limit, no more user can log in.
Configuring the maximum online duration of users

If an online user does not use services for a long time, the user still occupies resources. To
avoid a waste of resources, configure the maximum online duration for users. A user whose
online duration exceeds the limit is logged off forcibly. The virtual gateway still stores
information about the disconnected users.
Issue 02 (2012-03-30)

325

Forcibly disconnecting users from virtual gateways

An administrator can disconnect a user by specifying the user's name or ID or disconnect
all users from a virtual gateway. The virtual gateway still stores information about the
disconnected users.
SSL VPN Service

and IP forwarding.
l
The Web proxy service is based on the HTTPS protocol. Users access the internal Web
server through the SSL VPN gateway. The SSL VPN gateway functions as a proxy that
forwards data between users and the internal Web server. This function helps ensure that
access to the internal Web server is secure.
The port forwarding function allows applications to access internal servers using TCP.
Users can access the TCP-based services on the internal network. The typical port
forwarding services include Telnet login, desktop sharing, and mailing.
The IP forwarding function allows remote terminals to communicate with internal servers
at the network layer. For example, the remote terminals are allowed to ping internal servers.
SSL VPN License

The SSL VPN function is used with a license. To use the SSL VPN function, apply for and
purchase the following license from the Huawei local office:
l

NOTE
The maximum number of online SSL VPN users is limited by the license. The SSL VPN function has
multiple capacity licenses, which allow different numbers of access users. Select one or more capacity
licenses according to service requirements. The device supports a maximum of two online SSL VPN users
without a license.
6.3 Configuring Basic SSL VPN Functions

domain.

Before configuring basic SSL VPN functions, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the data required for the
domain.
To use an AR3200 as an SSL VPN gateway, you must configure and enable the basic SSL VPN
functions. If the basic SSL VPN functions are disabled, no user can access internal servers
Issue 02 (2012-03-30)

326

Before configuring basic SSL VPN functions, complete the following tasks:
l
Configuring IP addresses for the interfaces which will be configured as intranet and extranet
interfaces
Creating the AAA domain that you want to bind to the virtual gateway
Data Preparation
To configure the basic SSL VPN functions, you need the following data.
No.
Data
Name of the virtual gateway
Types and numbers of the interfaces to be configured as intranet and extranet

interfaces
AAA domain name to be bound to the virtual gateway
6.3.2 Creating a Virtual Gateway

The AR3200 functioning as an SSL VPN gateway manages users and services based on virtual
gateways.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
sslvpn gateway gateway-name
A virtual gateway is created and its view is displayed.

By default, no virtual gateway exists on an AR3200.
----End
6.3.3 Configuring Intranet and Extranet Interfaces

A virtual gateway has an intranet interface and an extranet interface.
Issue 02 (2012-03-30)

327

Figure 6-2 Interfaces of a virtual gateway
Remote terminal
Extranet
interface
Intranet
interface
LAN
Internet
SSL VPN gateway
Internal servers
When functioning as an SSL VPN gateway, the AR3200 provides two types of interfaces:
extranet interface and intranet interface.
l
An extranet interface connects to the Internet. Users on a virtual gateway can access the
web login page by using the extranet interface address.
An intranet interface connects to an internal server, allowing the virtual gateway to

communicate with the internal server.
NOTE
The intranet and extranet interfaces must be Layer 3 interfaces and have IP addresses.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The virtual gateway view is displayed.

Step 3 Run:
extranet interface interface-type interface-number
The extranet interface is configured.

By default, no extranet interface exists on a virtual gateway.
Step 4 Run:
intranet interface interface-type interface-number
The intranet interface is configured.

By default, no intranet interface exists on a virtual gateway.
----End
6.3.4 Binding an AAA Domain to the Virtual Gateway

To prevent unauthorized users from accessing internal resources and protect intranet security,
each virtual gateway must authenticate login users.
Issue 02 (2012-03-30)

328

Context
After being bound to an AAA domain, a virtual gateway performs AAA authentication for all
login users. Only the authenticated users are allowed to access internal resources.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
bind domain domain-name
An AAA domain is bound to the virtual gateway.

By default, no AAA domain is bound to a virtual gateway.
For the configuration of an AAA domain, see AAA Configuration in the Huawei AR3200
Series Enterprise Routers Configuration Guide - Security.
----End
6.3.5 Enabling Basic SSL VPN Functions

After you configure the basic SSL VPN functions, enable them to make the functions effective.
Prerequisites
The following basic SSL VPN configurations have been completed:
l
Extranet and intranet interfaces (See 6.3.3 Configuring Intranet and Extranet
Interfaces.)
AAA domain (See 6.3.4 Binding an AAA Domain to the Virtual Gateway.)
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
enable
The basic SSL VPN functions are enabled.

Issue 02 (2012-03-30)

329

By default, the basic SSL VPN functions are disabled.

----End

After the configurations of basic SSL VPN functions are complete, you can verify the
configurations.
Procedure
l
Run the display sslvpn gateway [ gateway-name ] command to check the virtual gateway
configurations.
----End

The user management functions include configuring user information, maximum number of
online users, and maximum online duration of users, and forcibly disconnecting users.
User management functions include:
l
Configuring user information

To log in to virtual gateways, each authorized user needs a user name and a password. All
the user names and passwords of the locally authenticated users are stored on virtual
gateways. After a user enters the user name and password, the virtual gateway checks
whether they are identical with the locally stored user name and password of this user. If
they are identical, the virtual gateway allows the user to log in.
NOTE
On a configuration terminal, only one user can log in to a virtual gateway.
Configuring the maximum number of online users

An administrator can limit the number of online users. When the number of online users
on the virtual gateway exceeds the limit, no more user can log in.
NOTE
The number of online SSL VPN users supported by the AR3200 is limited by the license. The number
of online SSL VPN users that each license support depends on the license level. The AR3200 supports
a maximum of two online SSL VPN users without a license. To enable the AR3200 to support more
online SSL VPN users, buy licenses from Huawei local office.
Configuring the maximum online duration of users

If an online user does not use services for a long time, the user still occupies resources. To
avoid a waste of resources, configure the maximum online duration for users. A user whose
online duration exceeds the limit is logged off forcibly. The virtual gateway still stores
information about the disconnected users.
Forcibly disconnecting users from virtual gateways

An administrator can disconnect a user by specifying the user's name or ID or disconnect
all users from a virtual gateway. The virtual gateway still stores information about the
disconnected users.
Issue 02 (2012-03-30)

330

Before configuring user management, complete the following task:
l
Creating a virtual gateway
Procedure
Step 1 Run:
system-view

Step 2 Run the following commands to configure the user name and password for logging in to the
virtual gateway:
1.
Run the aaa command to enter the AAA view.
2.
Run the local-user user-name service-type sslvpn command to set the user type to SSL
VPN user.
3.
Run the local-user user-name password { simple | cipher } password command to

configure a password for logging in to the SSL VPN virtual gateway.
4.
Run the quit command to return to the system view.

By default, no user name or password is configured on the AR3200.
Step 3 Run:

max-user number
The maximum number of online users allowed by the virtual gateway is configured.
NOTE
The number of online SSL VPN users supported by the AR3200 is limited by the license. The number of
online SSL VPN users that each license support depends on the license level. The AR3200 supports a
maximum of two online SSL VPN users without a license. To enable the AR3200 to support more online
SSL VPN users, buy licenses from Huawei local office.

max-online-time number
The maximum online duration of users allowed by the virtual gateway is configured.
By default, the maximum online duration of users allowed by the virtual gateway is 120 minutes.
cut user { name user-name | id user-id | all }
Users are forcibly disconnected from the virtual gateway.

----End
Checking the Configuration

After user management configurations are complete, you can verify the configurations.
Issue 02 (2012-03-30)

331

configurations.
Run the display sslvpn gateway gateway-name access-user [ user-name ] command to

view user information on the virtual gateway.
6.5 Configuring SSL VPN Services

and IP forwarding.

Before configuring SSL VPN services, familiarize yourself with the applicable environment,
complete the pre-configuration tasks, and obtain the data required for the configuration. This
will help you complete the configuration task quickly and accurately.
Figure 6-3 Remote access to internal servers using the SSL VPN gateway
Web server
Email
SSL VPN gateway
Remote host
Internet
LAN
Intranet
SSL tunnel
Internal host
FTP server
As shown in Figure 6-3, an SSL VPN gateway is located at an intranet's edge, and works with
the browsers installed on remote terminals or clients downloaded using browsers to protect user
data on the Internet. Additionally, the SSL VPN gateway functions as the proxy to allow users
to access internal servers.
and IP forwarding.
Before configuring an SSL VPN service, complete the following task:
l
Creating a virtual gateway
Data Preparation
To configure the SSL VPN serviced, you need the following data.
Issue 02 (2012-03-30)

332

No.
Data
Name of the virtual gateway
SSL VPN service name
Service parameters:
l Web proxy parameters: Web server's URL
l Port forwarding parameters: application server's IP address and port number
l IP forwarding parameters: IP address pool, ACL, routing mode, destination IP
address and mask of user route (for Split mode)
6.5.2 Creating a Virtual Gateway

The AR3200 functioning as an SSL VPN gateway manages users and services based on virtual
gateways.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
A virtual gateway is created and its view is displayed.

By default, no virtual gateway exists on an AR3200.
----End
6.5.3 Configuring the Web Proxy Service

The Web proxy service is based on the HTTPS protocol. Users access the internal Web server
Context
Figure 6-4 Web proxy service network
SSL VPN gateway
Remote terminal
Internet
Issue 02 (2012-03-30)
Web server
LAN

333

As shown in Figure 6-4, users access the internal Web server through the SSL VPN gateway.
The SSL VPN gateway functions as a proxy that forwards data between users and the internal
Web server. This function helps ensure that access to the internal Web server is secure.
The URL for the internal Web server must be specified so that users can access the Web server.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
service-type web-proxy resource resource-name
The Web proxy service is created and its view is displayed.

By default, the virtual gateway does not provide the Web proxy service.
description description
The description for the Web proxy service is configured.

Step 5 Run:
link url [ web-tunnel ]
A URL is configured for an internal Web server.

By default, an internal Web server does not have a URL.
NOTE
If the Web proxy function on the SSL VPN gateway is invalid, enable the tunnel mode; however, the tunnel
mode lowers security.
----End
6.5.4 Configuring the Port Forwarding Service

The port forwarding function allows applications to access internal servers using TCP.
Context
Figure 6-5 Port forwarding service network
Remote terminal
SSL VPN gateway

Internet
Issue 02 (2012-03-30)
Application server
LAN

334

As shown in Figure 6-5, users can access the TCP-based services on the internal network. The
typical port forwarding services include Telnet login, desktop sharing, and mailing.
NOTE
The TCP-based port numbers on the remote terminal and application server must be the same; otherwise,
the port forwarding service will fail.
The IP address and port number of the internal application server must be specified so that users
can access the application server.
To use the port forwarding service, a client software program is automatically downloaded from
the web page to transmit application-layer data through SSL connections. Users do not need to
upgrade their TCP program.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
service-type port-forwarding resource resource-name
The port forwarding service is created and its view is displayed.

By default, the virtual gateway does not provide the port forwarding service.
The description for the port forwarding service is configured.

Step 5 Run:
server ip-address ip-address
port port-number
The IP address and port number are configured for the port forwarding service.
By default, no IP address or port number is configured for the port forwarding service.
----End
6.5.5 Configuring the IP Forwarding Service

The SSL VPN gateway allows remote terminals to communicate with internal servers at the
network layer.
Issue 02 (2012-03-30)

335

Context
Figure 6-6 IP forwarding service network
SSL VPN gateway
Remote terminal
Internet
Application server
LAN
As shown in Figure 6-6, the SSL VPN gateway allows remote terminals to communicate with
internal servers at the network layer. For example, they can share files.
To use the IP forwarding service, client software specific to the IP forwarding service must be
downloaded from the web page and installed on the terminals. After the client software is
installed, a virtual network adapter is also installed on the terminal. The client software is
responsible for setting up an SSL connection between the terminal and gateway, requesting an
IP address for the virtual network adapter, and creating a route with the virtual network adapter
as outbound interface.
After an IP address pool is bound to the IP forwarding service, an IP address is allocated from
the IP address pool to the terminal.
To limit user access, you can use the bind acl command to apply an ACL to the IP forwarding
service. Alternatively, you can set the routing mode to Split. In the Split mode, a terminal can
only communicate with the servers in the specified network segment.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
service-type ip-forwarding resource resource-name
The IP forwarding service is created and its view is displayed.

By default, the virtual gateway does not provide the IP forwarding service.
The description for the IP forwarding service is configured.

Step 5 Run:
bind ip-pool pool-name
An IP address pool is bound to the IP forwarding service.

Issue 02 (2012-03-30)

336

By default, no IP address pool is bound to the IP forwarding service.

NOTE
If you configure a lease for the IP addresses in the IP address pool, ensure that the lease is longer than the
maximum online duration of SSL VPN users.

bind acl acl-number
An ACL is bound to the IP forwarding service.

Step 7 (Optional) Set the routing mode.
l Run the route-mode full command to set the routing mode to Full.
l Run the route-mode split command to set the routing mode to Split.
By default, the routing mode is Full.
If you set the routing mode to Split, perform step 8.
route-split ip address ip-address mask { mask-length | mask }
The network segment that users can access is specified.

NOTE
If users close the Internet Explorer when using the IP forwarding service, the running program cannot stop
and routes cannot be restored. In this situation, stop and restart the network adapter.
----End

After the configurations of SSL VPN services are complete, you can verify the service
configurations.
Procedure
l
configurations.
Run the display sslvpn gateway gateway-name resource class { web-proxy | portforwarding | ip-forwarding } command to check the resources on a virtual gateway.
----End

This section provides several SSL VPN configuration examples.
6.6.1 Example for Configuring the SSL VPN Gateway

This example describes how to control the access privileges of users who access the SSL VPN
gateway.
Issue 02 (2012-03-30)

337

Networking Environment
As shown in Figure 6-7, an enterprise's network connects to the Internet using a Router that
functions as an SSL VPN gateway. The marketing personnel on external networks, VIP
customers, and partners access the enterprise's intranet through the Router.
The networking requirements are as follows:
l
Marketing personnel access the internal Web server and mail server, share desktop with
the internal host 10.138.10.21, and ping the internal hosts 10.138.10.64-10.138.10.95.
VIP customers access the internal mail server and access the internal application server
through Telnet.
Partners access the internal Web server.
The Router must be configured to meet the preceding requirements.

Figure 6-7 SSL VPN gateway network
Marketing
personnel
Application
server
Eth2/0/0
Mail server
Eth1/0/0
LAN
Internet
Intranet
Router
Customers
Desktop
sharing host
Web server
Partner
l
Create virtual gateways on the Router for marketing personnel, VIP customers, and partners
and configure resources in the virtual gateways.
Data Preparation
l
Issue 02 (2012-03-30)
Data on the intranet

Resource Type
IP Address
Port Number
Web server
10.138.10.1
80
Application service
10.138.10.2
34
Mail server
10.138.10.3
995
Host for desktop sharing
10.138.10.21
3389

338

Resource Type
IP Address
Port Number
Remote host
10.138.10.32-10.138.10.192
Data on virtual gateways

User
Type
Virt
ual
Gate
way
Na
me
Extranet
Interfac
e
Intranet
Interfac
e
AAA
Dom
ain
User Name and

Password
Network
Segment
Mark
eting
perso
nnel
mark
et
Ethernet
2/0/0
Ethernet
1/0/0
defau
lt
Michael and
Michael123456
10.135.30.
0/24
VIP
custo
mers
custo
mer
Partn
ers
com
pany
Jessica and
Jessica654321
Ethernet
2/0/0
Ethernet
1/0/0
defau
lt
Amanda and
Amanda123456
10.136.30.
0/24
David and
David654321
Ethernet
2/0/0
Ethernet
1/0/0
defau
lt
Jack and Jack123456

John and John654321
10.137.30.
0/24
NOTE
Choose an AAA domain according to service requirements. For the configuration of an AAA domain,
see AAA Configuration in the Huawei AR3200 Series Enterprise Routers Configuration Guide Security.
IP address of extranet interface Ethernet2/0/0: 1.1.1.1/24
IP address of intranet interface Ethernet1/0/0: 10.138.10.254/24
IP address pool: 10.139.30.0/24

NOTE
Ensure that routes are available between the Router, enterprise intranet, and users.
Before using the AR3200 as an SSL VPN gateway, configure the Router as an HTTPS server. For the
configuration procedure, see "SSL Configuration" in the Huawei AR3200 Series Enterprise Routers
Configuration Guide - Security.
Procedure
l
Configure the virtual gateway for marketing personnel.

1.
Configure an IP address pool.

[Huawei] sysname Router
[Router] ip pool market_pool
Info:It's successful to create an IP address pool.
[Router-ip-pool-market_pool] network 10.139.30.0 mask 24
[Router-ip-pool-market_pool] quit
Issue 02 (2012-03-30)

339

2.
Create a virtual gateway named market.

[Router] sslvpn gateway market
3.
Configure the intranet/extranet interfaces and bind an AAA domain to the virtual
gateway.
[Router-sslvpn-market]
4.
extranet interface ethernet 2/0/0

intranet interface ethernet 1/0/0
bind domain default
enable
Configure user information.

[Router-sslvpn-market] user Michael password cipher Michael123456
[Router-sslvpn-market] user Jessica password cipher Jessica654321
5.
Configure SSL VPN services.

# Configure the Web proxy service.
[Router-sslvpn-market] service-type web-proxy resource market_web-proxy
[Router-sslvpn-market-wp-res-market_web-proxy] link http://
10.138.10.1:80/
[Router-sslvpn-market-wp-res-market_web-proxy] quit
# Configure the port forwarding service to allow marketing personnel to access the
mail server and share desktop with the internal host 10.138.10.21.
[Router-sslvpn-market] service-type port-forwarding resource market_portforwarding
[Router-sslvpn-market-pf-res-market_port-forwarding] server ip-address
10.138.10.21 port 3389
[Router-sslvpn-market-pf-res-market_port-forwarding] quit
# Configure the IP forwarding service to allow marketing personnel to ping the internal
hosts 10.138.10.64-10.138.10.95.
[Router-sslvpn-market] service-type ip-forwarding resource market_ipforwarding
[Router-sslvpn-market-if-res-market_ip-forwarding] bind ip-pool
market_pool
[Router-sslvpn-market-if-res-market_ip-forwarding] route-mode split
[Router-sslvpn-market-if-res-market_ip-forwarding] route-split ip address
10.138.10.64 mask 27
[Router-sslvpn-market-if-res-market_ip-forwarding] quit
[Router-sslvpn-market] quit
NOTE
To ensure that reachable routes are available between the enterprise intranet and virtual network
adapters of the SSL VPN users, configure a dynamic routing protocol on the Router and
configure the routing protocol to import user network routes (UNRs).
6.
Verify the configuration.

Open the Internet Explorer on the terminal, such as a computer, and enter https://
1.1.1.1/sslvpn to access the login page. Enter the user name and password, and select
the virtual gateway market. After authentication, you can see a resource list on the
Web page, including the Web server, mail server, and host for desktop sharing, and
ping the hosts on 10.138.10.64-10.138.10.95.
Configure the virtual gateway for VIP customers.

1.
Issue 02 (2012-03-30)
Create a virtual gateway named customer.

340

[Router] sslvpn gateway customer
2.
gateway.
[Router-sslvpn-customer]
3.

bind domain default
enable

[Router-sslvpn-customer] user Amanda password cipher Amanda123456
[Router-sslvpn-customer] user David password cipher David654321
4.

# Configure the port forwarding service to allow VIP customers to access the mail
server and log in to the application server through Telnet.
[Router-sslvpn-customer] service-type port-forwarding resource
customer_port-forwarding
[Router-sslvpn-customer-pf-res-customer_port-forwarding] server ipaddress 10.138.10.3 port 995
[Router-sslvpn-customer-pf-res-customer_port-forwarding] quit
[Router-sslvpn-customer] quit
5.

the virtual gateway customer. After authentication, you can see a resource list on the
Web page, including the mail server and application server.
Configure the virtual gateway for partners.

1.
Create a virtual gateway named company.

[Router] sslvpn gateway company
2.
gateway.
[Router-sslvpn-company]
3.

bind domain default
enable

[Router-sslvpn-company] user Jack password cipher Jack123456
[Router-sslvpn-company] user John password cipher John654321
4.

# Configure the Web proxy service.
[Router-sslvpn-company] service-type web-proxy resource company_webproxy
[Router-sslvpn-company-wp-res-company_web-proxy] link http://
10.138.10.1:80/
[Router-sslvpn-company-wp-res-company_web-proxy] quit
[Router-sslvpn-company] quit
5.
Issue 02 (2012-03-30)

341

the virtual gateway company. After authentication, you can see a resource list on the
Web page.
----End
Configuration Files
#
sysname Router
#
interface Ethernet 2/0/0
ip address 1.1.1.1 255.255.255.0
#
interface Ethernet 1/0/0
ip address 10.138.10.254 255.255.255.0
#
ip pool market_pool
network 10.139.30.0 mask 24
#
sslvpn gateway market
extranet interface Ethernet 2/0/0
intranet interface Ethernet 1/0/0
bind domain default
user liming password cipher !9$"OZ$+1"-',917]_2Y71!!
user wangjun password cipher =S@P;D^[S_2)S(YTABR0IQ!!
enable
service-type web-proxy resource market_web-proxy
link http://10.138.10.1:80/
service-type port-forwarding resource market_port-forwarding
server ip-address 10.138.10.21 port 3389
service-type ip-forwarding resource market_ip-forwarding
bind ip-pool market_pool
route-mode split
route-split ip address 10.138.10.64 mask 27
#
sslvpn gateway customer
bind domain default
user zhanghong password cipher B193FII=.MY%X)AG\U/NCA!!
user huwei password cipher P<9=H7#P["9%X)AG\U/NCA!!
enable
service-type port-forwarding resource customer_port-forwarding
server ip-address 10.138.10.3 port 995
#
sslvpn gateway company
bind domain default
user jack password cipher N`C55QK<`=/Q=^Q`MAF4<1!!
user john password cipher +Q4Z3D_*-N[Q=^Q`MAF4<1!!
enable
service-type web-proxy resource company_web-proxy
link http://10.138.10.1:80/
#
return
Issue 02 (2012-03-30)

342

AR3200 Configuration Guide - VPN

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AR3200 Configuration Guide - VPN

Uploaded by

Copyright:

Available Formats

Huawei AR3200 Series Enterprise Routers

Configuration Guide - VPN

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2012. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential

Huawei AR3200 Series Enterprise Routers

About This Document

About This Document

Data configuration engineers

Network monitoring engineers

System maintenance engineers

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

Indicates a tip that may help you solve a problem or save

Provides additional information to emphasize or supplement

Huawei Proprietary and Confidential

Huawei AR3200 Series Enterprise Routers

About This Document

The keywords of a command line are in boldface.

Command arguments are in italics.

Items (keywords or arguments) in brackets [ ] are optional.

Optional items are grouped in braces and separated by vertical

Optional items are grouped in brackets and separated by vertical

Optional items are grouped in braces and separated by vertical

Optional items are grouped in brackets and separated by vertical

The parameter before the & sign can be repeated 1 to n times.

A line starting with the # sign is comments.

Interface Numbering Conventions

Changes in Issue 02 (2012-03-30)

6.4 Managing SSL VPN Users

6.6.1 Example for Configuring the SSL VPN Gateway

Changes in Issue 01 (2011-12-30)

Huawei Proprietary and Confidential

Huawei AR3200 Series Enterprise Routers

2 BGP MPLS IP VPN Configuration..........................................................................................41

Huawei Proprietary and Confidential

Huawei AR3200 Series Enterprise Routers

2.2 BGP/MPLS IP VPN Features Supported by the AR3200................................................................................43

Huawei Proprietary and Confidential

Huawei AR3200 Series Enterprise Routers

2.8.6 Checking the Configuration.....................................................................................................................91

Huawei Proprietary and Confidential

Huawei AR3200 Series Enterprise Routers

2.15.3 Checking the Network Connectivity and Reachability.......................................................................123

Huawei Proprietary and Confidential

Huawei AR3200 Series Enterprise Routers

3.7 Configuration Examples.................................................................................................................................227

Huawei Proprietary and Confidential

Huawei AR3200 Series Enterprise Routers

4.8.2 Example for Configuring IKE Negotiation Using Default Settings......................................................279

5 DSVPN Configuration............................................................................................................. 304

6 SSL VPN Configuration...........................................................................................................323

Huawei Proprietary and Confidential

Huawei AR3200 Series Enterprise Routers

6.6.1 Example for Configuring the SSL VPN Gateway.................................................................................337

Huawei Proprietary and Confidential

Huawei AR3200 Series Enterprise Routers

About This Chapter

Huawei Proprietary and Confidential

Huawei AR3200 Series Enterprise Routers

1.1 Introduction to GRE

1.2 GRE Features Supported by the AR3200