7.2 BGP/MPLS VPN Configuration

Operation Manual – VPN
H3C SecPath Series Security Products
Table of Contents
Table of Contents
Chapter 1 VPN Overview .............................................................................................................. 1-1
1.1 VPN Overview.................................................................................................................... 1-1
1.1.1 Features of VPN...................................................................................................... 1-1
1.1.2 Benefits of VPN ....................................................................................................... 1-1
1.1.3 Structure of VPN network........................................................................................ 1-2
1.2 Fundamental Technology of VPN...................................................................................... 1-2
1.2.1 Basic Network Application of VPN .......................................................................... 1-2
1.2.2 Mechanism of VPN ................................................................................................. 1-3
1.3 Classification of VPN ......................................................................................................... 1-5
Chapter 2 L2TP Configuration ..................................................................................................... 2-1
2.1 Introduction to L2TP .......................................................................................................... 2-1
2.1.1 VPDN Overview ...................................................................................................... 2-1
2.1.2 Introduction to L2TP Protocol.................................................................................. 2-2
2.2 LAC Configuration.............................................................................................................. 2-6
2.2.1 Enabling L2TP......................................................................................................... 2-7
2.2.2 Creating L2TP Group .............................................................................................. 2-7
2.2.3 Setting Condition Triggering L2TP Tunnel Setup Request and LNS Address ....... 2-8
2.2.4 Setting Tunnel Name .............................................................................................. 2-9
2.2.5 Setting Tunnel Authentication and Password ....................................................... 2-10
2.2.6 Configuring AVP Hiding ........................................................................................ 2-10
2.2.7 Setting Hello Interval in Tunnel ............................................................................. 2-11
2.2.8 Setting Username, Password and Local User Authentication .............................. 2-11
2.2.9 Disconnecting an L2TP Connection...................................................................... 2-12
2.2.10 Setting Flow Control Function of Tunnel............................................................. 2-13
2.2.11 Setting the L2TP Session Idle-Timeout Timer .................................................... 2-13
2.2.12 Configuring the Tunnel-Hold Function of L2TP................................................... 2-13
2.2.13 Setting LAC to Function as Client ....................................................................... 2-14
2.3 LNS Configuration............................................................................................................ 2-16
2.3.1 Enabling L2TP....................................................................................................... 2-16
2.3.2 Enabling L2TP Multi-Domain Function ................................................................. 2-17
2.3.3 Creating L2TP Group ............................................................................................ 2-17
2.3.4 Creating Virtual Template ..................................................................................... 2-18
2.3.5 Setting Parameters for Call Receiving .................................................................. 2-18
2.3.6 Setting Local Name............................................................................................... 2-19
2.3.7 Setting Tunnel Authentication and Password ....................................................... 2-20
2.3.8 Setting Transfer Mode of AVP Data...................................................................... 2-20
2.3.9 Setting Hello Interval in Tunnel ............................................................................. 2-21
i
Operation Manual – VPN
H3C SecPath Series Security Products
Table of Contents
2.3.10 Enabling Mandatory Local CHAP Authentication................................................ 2-21
2.3.11 Forcing LCP to Re-negotiate............................................................................... 2-22
2.3.12 Setting Local Address and Assigning Address Pool ........................................... 2-23
2.3.13 Setting Username, Password and User Authentication...................................... 2-24
2.3.14 Disconnecting an L2TP Connection.................................................................... 2-24
2.3.15 Enabling/Disabling Flow Control Function of Tunnel .......................................... 2-24
2.3.16 Setting the L2TP Session Idle-Timeout Timer .................................................... 2-25
2.3.17 Configuring EAD Support for L2TP ..................................................................... 2-25
2.4 Displaying and Debugging L2TP ..................................................................................... 2-26
2.5 L2TP Configuration Example........................................................................................... 2-27
2.5.1 NAS-initialized VPN Networking ........................................................................... 2-27
2.5.2 Client-initialized VPN Networking.......................................................................... 2-28
2.5.3 L2TP Multi-Domain Networking ............................................................................ 2-30
2.5.4 Using LAC as L2TP Client .................................................................................... 2-33
2.5.5 Complex Network Design...................................................................................... 2-35
2.6 L2TP Troubleshooting ..................................................................................................... 2-36
Chapter 3 GRE Configuration ...................................................................................................... 3-1
3.1 Brief Introduction to GRE................................................................................................... 3-1
3.2 GRE Configuration............................................................................................................. 3-4
3.2.1 Creating Virtual Tunnel Interface ............................................................................ 3-4
3.2.2 Setting Encapsulation Mode ................................................................................... 3-5
3.2.3 Specifying Tunnel Source ....................................................................................... 3-5
3.2.4 Specifying Tunnel Destination................................................................................. 3-6
3.2.5 Assigning Network Address to Tunnel Interface ..................................................... 3-6
3.2.6 Configuring End-to-End Verification on Both Ends of Tunnel................................. 3-7
3.2.7 Setting Identification Key of Tunnel Interface ......................................................... 3-7
3.2.8 Configuring Routing via Tunnel............................................................................... 3-8
3.2.9 Configuring the Keepalive Function ........................................................................ 3-8
3.3 Displaying and Debugging GRE ........................................................................................ 3-9
3.4 Typical Configuration Examples of GRE ........................................................................... 3-9
3.5 GRE Troubleshooting ...................................................................................................... 3-11
Chapter 4 IPsec Configuration..................................................................................................... 4-1
4.1 IPsec Overview .................................................................................................................. 4-1
4.1.1 IPsec ....................................................................................................................... 4-1
4.1.2 Overview of Encryption Card .................................................................................. 4-2
4.1.3 IPsec Basic Concepts ............................................................................................. 4-2
4.1.4 Introduction to IPsec Multi-Instance ........................................................................ 4-6
4.1.5 IPsec on Comware.................................................................................................. 4-7
4.2 IPsec Configuration ........................................................................................................... 4-8
4.2.1 Defining ACL ........................................................................................................... 4-9
4.2.2 Defining an IPsec Proposal................................................................................... 4-10
4.2.3 Creating an IPsec Policy ....................................................................................... 4-13
ii
Operation Manual – VPN
H3C SecPath Series Security Products
Table of Contents
4.2.4 Configuring IPsec Policy Template ....................................................................... 4-21
4.2.5 Applying IPsec Policy Group to Interface.............................................................. 4-23
4.2.6 Disabling Next-Payload Field Checking................................................................ 4-23
4.2.7 Configuring IPsec Fragments Buffering ................................................................ 4-24
4.2.8 Configuring the Encryption Card (Optional) .......................................................... 4-25
4.3 Displaying and Debugging IPsec..................................................................................... 4-27
4.3.1 Displaying and Debugging over IPsec Module on Comware Platform ................. 4-27
4.3.2 Displaying and Debugging Encryption Card Information ...................................... 4-29
4.4 Typical IPsec Configuration Example .............................................................................. 4-32
4.4.1 Establishing SAs Manually.................................................................................... 4-32
4.4.2 Establishing ISAKMP SAs..................................................................................... 4-35
4.4.3 Implementing Encryption/Decryption and Authentication on Encryption Card ..... 4-38
4.4.4 Configuration Example of SA Setup Between a Firewall and the Virtual Address of a
VRRP Standby Group .................................................................................................... 4-41
4.4.5 IPsec/IKE Multi-Instance Configuration Example ................................................. 4-46
4.5 IPsec Troubleshooting ..................................................................................................... 4-50
Chapter 5 IKE Configuration ........................................................................................................ 5-1
5.1 IKE Overview ..................................................................................................................... 5-1
5.1.1 Brief Introduction to IKE .......................................................................................... 5-1
5.1.2 Preparation for IKE Configuration ........................................................................... 5-3
5.2 IKE Configuration............................................................................................................... 5-4
5.2.1 Introduction to IKE Configuration ............................................................................ 5-4
5.2.2 Setting a Name for the Local Security GW ............................................................. 5-4
5.2.3 Defining IKE Proposal ............................................................................................. 5-4
5.2.4 Configuring IKE Peer .............................................................................................. 5-8
5.2.5 Configuring Keepalive Timer................................................................................. 5-11
5.2.6 Disabling IKE DH Hardware Acceleration............................................................. 5-13
5.3 Displaying and Debugging IKE ........................................................................................ 5-13
5.4 Typical Configuration of IKE ............................................................................................ 5-14
5.4.1 Typical IKE Configuration Example....................................................................... 5-14
5.4.2 Typical IKE Aggressive Mode and NAT Traversal Configuration Example .......... 5-15
5.5 IKE Fault Diagnosis and Troubleshooting ....................................................................... 5-18
Chapter 6 DVPN Configuration .................................................................................................... 6-1
6.1 Introduction to DVPN ......................................................................................................... 6-1
6.1.1 Overview ................................................................................................................. 6-1
6.1.2 Basic DVPN Elements ............................................................................................ 6-1
6.1.3 Implementation........................................................................................................ 6-3
6.1.4 Basic Network Structure.......................................................................................... 6-4
6.1.5 Traditional VPN versus DVPN ................................................................................ 6-5
6.2 DVPN Configuration .......................................................................................................... 6-7
6.2.1 Basic DVPN Configuration ...................................................................................... 6-9
6.2.2 Configuring the Tunnel Interface........................................................................... 6-12
iii
Operation Manual – VPN
H3C SecPath Series Security Products
Table of Contents
6.2.3 Configuring a DVPN class..................................................................................... 6-15
6.2.4 Configuring a DVPN policy.................................................................................... 6-18
6.2.5 Displaying and Debugging DVPN ......................................................................... 6-21
6.3 DVPN Implementation ..................................................................................................... 6-22
6.3.1 NAT traversal ........................................................................................................ 6-22
6.3.2 GRE Cooperation .................................................................................................. 6-26
Chapter 7 BGP/MPLS VPN Configuration ................................................................................... 7-1
7.1 BGP/MPLS VPN Overview ................................................................................................ 7-1
7.1.1 BGP/MPLS VPN Model........................................................................................... 7-2
7.1.2 BGP/MPLS VPN Implementation............................................................................ 7-4
7.1.3 Introduction to Multi-Role Host Features ................................................................ 7-6
7.1.4 OSPF VPN Extension ............................................................................................. 7-6
7.1.5 Multi-AS BGP/MPLS VPN..................................................................................... 7-10
7.2 BGP/MPLS VPN Configuration........................................................................................ 7-14
7.2.1 Configuring CE ...................................................................................................... 7-14
7.2.2 Configuring PE ...................................................................................................... 7-15
7.2.3 Configuring P......................................................................................................... 7-29
7.3 Displaying and Debugging BGP/MPLS VPN................................................................... 7-29
7.4 BGP/MPLS VPN Configuration Example ........................................................................ 7-31
7.4.1 Integrated BGP/MPLS VPN Networking ............................................................... 7-31
7.4.2 Configuring BGP/MPLS VPN using GRE Tunnel ................................................. 7-37
7.4.3 Extranet Networking.............................................................................................. 7-39
7.4.4 Hub&Spoke Networking ........................................................................................ 7-44
7.4.5 CE Dual-Homed Networking ................................................................................. 7-49
7.4.6 Multi-Role Host Networking................................................................................... 7-55
7.4.7 OSPF Multi-Instance Sham Link Networking........................................................ 7-57
7.4.8 OSPF Multi-Instance CE Networking.................................................................... 7-62
7.4.9 Configuring Inter-Provider Backbones Option A ................................................... 7-63
7.4.10 Configuring Inter-Provider Backbones Option B ................................................. 7-76
7.4.11 Configuring Inter-Provider Backbones Option C................................................. 7-83
iv
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 1 VPN Overview
Chapter 1 VPN Overview
1.1 VPN Overview
Along with the increasingly wide application of the Internet, the virtual private network
(VPN) emerged to construct private networks on public networks. “virtual” here mainly
indicates that VPN is a kind of logical networks.
Employees travel around on business more and more frequently; foreign services and
customers are scattered more widely; cooperation is conducted with a growing number
of partners-all these are sound quite familiar to all the growing companies. More and
more companies therefore turn to the Internet for market promotion, sales, aftersales
services, and also for conducting training, cooperation and other counseling activities.
This provides a broad market for the application of VPN.
1.1.1 Features of VPN
z
Different from a traditional network, VPN does not exist physically. It is a kind of
logical network, a virtual network formed through resources collocation employing
the current public network.
z
Each VPN is only for a particular enterprise or group of users. For VPN users, VPN
is just like any traditional private network. As a kind of private network, VPN keeps
resources independent of the underlying network, meaning resources of each
VPN are normally inaccessible for other VPNs over the underlying network and
users outside this VPN. It also delivers adequate security, safeguarding the
internal information of VPN against external invasion.
z
VPN is a kind of upper layer service but not simple. It establishes network
interconnection between private network users, including network topology inside
VPN, route calculation, joining and leaving of members, etc. Thus, VPN
technology is much more complicated, compared to common point-to-point
applications alike.
1.1.2 Benefits of VPN
VPN allows you to:
z
Establish reliable and safe connection between remote users, oversea agencies,
partners, suppliers and company headquarters, ensuring security of data
transmission. This advantage is of special significance to the amalgamation of
E-business or financial network with communication network.
z
Provide information communication over public networks, thus allowing
enterprises to connect with remote offices, staff traveling on business and
1-1
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 1 VPN Overview
business partners at a low cost, while improving utility of network resources. This
will help Internet Service Providers (ISPs) increase profits.
z
Add or delete users through software configuration rather than changing hardware
facilities, thus delivering great flexibility.
z
Support mobile access of VPN users at any time in any place, thus meeting
growing mobile service demands.
z
Create VPN with QoS (for example, MPLS VPN), providing differentiated services
for VPN users and obtaining more profits by pricing these services differently.
1.1.3 Structure of VPN network
VPN comprises a group of sites. A site might join one or more VPNs, but any two sites
are IP reachable only if they belong to the same VPN. According to its standard
definition, VPN with all its Sites coming from a single enterprise is called Intranet, and
cross-enterprise VPN is by contrast called Extranet.
Site 5
Site 2
Site 1
Site 4
VPN 1
Site 3
VPN 3
VPN 2
Figure 1-1 The composition of VPN
The above chart demonstrates the relationship between five sites and three VPNs.
z
VPN1---Site2, Site4
z
VPN2---Site1, Site3, Site4
z
VPN3---Site1, Site5
1.2 Fundamental Technology of VPN
1.2.1 Basic Network Application of VPN
Take an enterprise as an example. Its intranet through VPN is shown in following figure.
1-2
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 1 VPN Overview
Remote
Subscriber
PSTN/ISDN
POP
PC
POP
Internet
ISP IP
Frame Relay
ATM
POP
Corporate
Headquarter
Cooperator
Internal Server
Figure 1-2 Diagram of VPN application
It can be seen that enterprise internal resource sharers can access local ISP at its POP
(Point of Presence) server via PSTN/ISDN network or local network and access the
internal resources of the company. With traditional WAN networking technology,
however, they need to be connected using dedicated lines to achieve the same
purpose. VPN allows remote end users and clients in other cities to access enterprise
internal resources without being authorized by their local ISPs, which is of great
significance for staffs on business trip and geographically scattered clients.
An enterprise can deploy VPN services simply by setting up a VPN-supported server
for resource sharing (for example, a Windows NT server or a router supporting VPN).
The resource sharers connect to local POP server via PSTN/ISDN or LAN before they
directly call the remote server (VPN server) of the enterprise. The call process is
completed by ISP network access server (NAS) and VPN server together.
1.2.2 Mechanism of VPN
PSTN/ISDN
VPN
Subscriber
NAS
VPN Server
Figure 1-3 Diagram of accessing VPN
As shown in the above figure, through PSTN/ISDN network, a subscriber accesses ISP
NAS. After NAS server recognizes that this is a VPN user by checking user name or
access number, it establishes a connection, which is called tunnel, to the user’s
destination VPN server. Then NAS encapsulates the user data into IP packets and
transmits it to the VPN server through this tunnel. Upon the receipt of this IP packet,
VPN server removes the encapsulation to get the original data. In the opposite direction,
the packet is handled likewise. On both sides of the tunnel, packets can be encrypted to
make other users on the Internet unable to access them, so they are safe and authentic.
For users, tunnels are only the logical extension of their PSTN/ISDN links and thus can
be operated like the physical links.
1-3
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 1 VPN Overview
Tunnels are implemented using tunneling protocols. Tunneling protocols are divided
into layer 2 tunneling protocols and layer 3 tunneling protocols depending on at which
layer of OSI model tunnel is implemented.
I. Layer 2 tunneling protocols
Layer 2 tunneling protocols encapsulate PPP frames entirely into internal tunnels. The
existing layer 2 tunneling protocols include:
z
PPTP (Point to Point Tunneling Protocol): Supported by companies like Microsoft,
Ascend, and 3Com and in OS of Windows NT 4.0 and its later versions. This
protocol supports tunneling encapsulation of PPP in IP networks. As a call control
and management protocol, PPTP uses an enhanced Generic Routing
Encapsulation (GRE) technology to provide the encapsulation service with flow
control and congestion control for transmitted PPP packets.
z
L2F (Layer 2 Forwarding): Supported by Nortel and some other companies. It
supports the tunnel encapsulation for the higher-level link layer and physically
separates dial-up server and dial-up connection.
z
L2TP (Layer 2 Tunneling Protocol): Drafted by IETF, Microsoft and other
companies. Absorbing the advantages of above two protocols, it is accepted by
most companies and has become a standard RFC. L2TP provides both dial-up
VPN service and leased line VPN service.
II. Layer 3 tunneling protocols
Both start point and end point of layer 3 tunneling protocol are in ISP. PPP session
terminates at NAS. Only layer 3 packets are carried in tunnels. The existing layer 3
tunneling protocols include:
z
GRE (Generic Routing Encapsulation), which is used to encapsulate a network
layer protocol into another one.
z
IPsec (IP security), which provides a complete architecture of data security on IP
networks by using several protocols rather than a single one, such as AH
(Authentication Header), ESP (Encapsulating Security Payload), and IKE (Internet
Key Exchange).
GRE and IPsec mainly apply in private line VPN.
III. Contrast between layer 2 tunneling protocols and layer 3 tunneling
protocols
Compared with layer 2 tunneling protocols, the advantages of layer 3 tunneling
protocols are their security, scalability and reliability. In terms of security, layer 2 tunnel
imposes great challenges to security of user networks and firewall technologies while
layer 3 tunnel does not, because layer 2 tunnel generally terminates at customer
premise equipment and layer 3 tunnel at ISP gateway.
1-4
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 1 VPN Overview
Concerning scalability, layer 2 tunnel is not as efficient as layer 3 tunnel in transmission
due to the encapsulation of entire PPP frames. Besides, its PPP session runs through
the entire tunnel and terminates at customer premise equipment, and thus requires the
user-side gateway to store a large amount of PPP session status and information,
which may not only overload the system but also decrease the scalability. The
introduction of tunneling latency may incur such problems as PPP session timeout in
time sensitive LCP and NCP negotiations of PPP. On the contrary, layer 3 tunnel
terminates within ISP gateway, and PPP session terminates at NAS; thus user gateway
needs not to manage and maintain status of each PPP session, and thereby reduces
system load.
Normally, layer 2 tunneling protocols and layer 3 tunneling protocols are used
separately. The reasonable combination of two types of protocols, however, may
deliver better security and functions (for example, using L2TP and IPsec together).
1.3 Classification of VPN
IP VPN means emulating private line service of WAN (such as remote dial-up and DDN)
over IP networks (including the Internet or dedicated IP backbone). IP VPN is classified
as follows:
I. Classified by operation mode
1)
CPE-based VPN (Customer Premises Equipment based VPN)
Users not only have to install expensive devices and special authentication tools, but
also maintain complex VPN (such as channel maintenance and bandwidth
management). Networking in this way features both high complexity and low service
scalability.
2)
NBIP-VPN (Network-based VPN)
The maintenance of VPN (permitting users to conduct service management and control
to some extent) is conducted by ISP, and all functions are implemented at network
device side, so as to reduce users’ investment, reinforce the flexibility and scalability of
services, and bring new incomes to ISP.
II. Classified by service application
1)
Intranet VPN
Intranet VPN interconnects points distributed inside an enterprise by making use of
public network. It is an extended or substitute form of traditional private network or
other enterprise network.
2)
Access VPN
Access VPN allows remote users like staff traveling on business and remote small
offices to establish private network connections with the intranet and extranet of their
1-5
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 1 VPN Overview
enterprise over a public network. Access VPN provides two types of connections:
client-initiated VPN connection and NAS-initiated VPN connection.
3)
Extranet VPN
Extranet VPN extends an enterprise network to suppliers, cooperators and clients by
using VPN, allowing different enterprises to construct VPN over public networks.
III. Classified by networking model
1)
VLL
Virtual Leased Line (VLL) is emulation to traditional leased line services. By emulating
leased line over IP networks, it provides asymmetric and low cost “DDN” service. From
the view of end users of VLL, it is similar to traditional leased lines.
2)
VPDN
Virtual Private Dial Network (VPDN) means implementing virtual private network by
employing the dial-up function of public networks (such as ISDN and PSTN) and
access networks, to provide access service for enterprises, small ISPs, and mobile
businesspersons.
3)
VPLS service
Virtual Private LAN Segment (VPLS) interconnects LANs via virtual private network
segments in virtue of IP public networks. It is an extension of LANs on IP public
networks.
4)
VPRN
Virtual Private Routing Network (VPRN) interconnects headquarters, branches and
remote offices via network management virtual router in virtue of IP public networks.
There are two kinds of VPRN services: VPRN implemented using traditional VPN
protocol (IPsec, GRE, etc.) and VPRN by means of MPLS.
IV. Classified by working layer
1)
L3VPN: including BGP/MPLS VPN, IPsec VPN, GRE VPN, etc.
2)
L2VPN: including MPLS L2VPN in Martini mode, MPLS L2VPN in Kompella mode,
MPLS L2VPN in SVC mode, VPLS and static CCC configuration.
3)
VPDN: including L2TP, PPTP, etc.
1-6
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
Chapter 2 L2TP Configuration
2.1 Introduction to L2TP
2.1.1 VPDN Overview
Virtual Private Dial Network (VPDN) means implementing virtual private network by
employing the dial-up function of public networks (such as ISDN and PSDN) and
access networks, thus providing access service for enterprises, small ISPs and mobile
businessmen.
VPDN sets up safe virtual private networks in public networks for enterprises by making
use of special network encryption protocols. In this way, overseas agencies and
traveling staff of an enterprise can access the headquarters' network by making use of
encrypted virtual tunnels over public networks, while other users in public networks
have no access to internal resources of the enterprise network through virtual tunnels.
There are two VPDN implementation approaches:
1)
NAS sets up tunnel with VPDN gateway by making use of a tunneling protocol. In
this way, users’ PPP connections are directly connected to enterprise’s gateway.
Protocols available now are L2F and L2TP. This approach has a great deal of
advantages: transparent tunnel setup process from the perspective of users,
network access with one login, user authentication and address assignment by
enterprise network without occupying public addresses, and support to a wide
range of platforms for network access. It requires however: a) NAS supporting the
VPDN protocol, and b) authentication system supporting VPDN attributes, and c)
router or special VPN server working as gateway.
2)
Client sets up tunnel with VPDN gateway. In this way, client first creates
connection with the Internet, and then sets up a tunnel with gateway by using the
special client software (for example, L2TP client supported by Win2000). This
approach allows users to access network by whatever available means and
wherever they are without the intervention of ISP. The bad news is the limitation in
platform, meaning users need to install special software (usually Win2000
platform).
There are three types of VPDN tunneling protocols: PPTP, L2F, and L2TP, with L2TP
being most popular.
2-1
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
2.1.2 Introduction to L2TP Protocol
I. Protocol background
PPP defined a kind of encapsulation technology that allows the transmission of various
kinds of data packets on layer 2 point-to-point links. Meanwhile, PPP is performed
between users and NAS, with endpoint of layer 2 link and PPP session sticking on the
same hardware.
L2TP provides tunnel transmission for PPP link layer packets. It extents PPP model in
that it permits link endpoint of layer 2 and PPP session point staying at different devices
and allows information interaction by using packet switching network technologies. It
combines the advantages of PPTP and L2F. Therefore, it becomes the industrial
standard of IETF in layer 2 tunneling.
II. Typical L2TP network application
Figure 2-1 shows a typical network where VPDN is constructed using L2TP:
Remote user
LAC
PC
PSTN/ISDN
Internet
backbone netw ork
LNS
L2TPchannel
NAS
Remote user
internet server
Figure 2-1 Network diagram of typical VPDN application created by L2TP
In this figure, LAC stands for L2TP Access Concentrator, a switching network device
with the capability to process PPP and L2TP requests. Usually, LAC functions as
network access server (NAS) to provide access service to users by making use of
PSTN/ISDN. LNS stands for L2TP network server, a device functioning in the PPP
system as L2TP server.
LAC lies between LNS and remote system (remote users and remote branches) to
transmit packets between them, encapsulate packets from remote system in L2TP
protocol and send the encapsulated packets to LNS, and decapsulate packets from
LNS and send the remaining part to remote system. Local connection or PPP link can
be adopted between LAC and remote system, but PPP link is always involved in VPDN
applications. As one end of the L2TP tunnel, LNS is the peer device of LAC, and also is
the logic terminating point of PPP session transmitted in tunnel by LAC.
2-2
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
III. Technology details of L2TP protocol
1)
Architecture of L2TP protocol
PPP Frame
L2TP Data message
L2TP Data message
(unreliable)
L2TP Control message
L2TP Control tunnel
(reliable)
Packet transmission packet (UDP,……)
Figure 2-2 Architecture of L2TP protocol
The architecture of L2TP protocol shown above describes the relationship between
PPP frame, control tunnel and data tunnel. PPP frame is transmitted in unreliable L2TP
data channel. Control message is transmitted in reliable L2TP control channel.
Usually L2TP data is carried in UDP packets for transmission. L2TP registers the UDP
port 1701, but this port is only used for the tunnel setup at the early stage. L2TP tunnel
initiator selects an arbitrary port from available ones (unnecessarily being 1701) and
forwards packets to 1701 port of the receiver. After the receiver receives the packets, it
also selects a free port randomly (unnecessarily being 1701) and forwards packets
again to the specified port of the initiator. Thus, ports of the two sides are determined.
They will remain unchanged until the tunnel connection is disconnected.
2)
Definitions of tunnel and session
There are two kinds of connections between LNS-LAC pairs: Tunnel connection and
Session connection. Tunnel connections define pairs of LNS and LAC while Session
connections are multiplexed in a Tunnel connection to present PPP sessions in it.
Several L2TP tunnels can be created between a LNS-LAC pair, which consist of a
control connection, and one or several Sessions. Session connections can be set up
only after tunnels are created successfully (including such information exchange as ID
protection, L2TP version, frame type, hardware transmission type, etc.). Each session
connection corresponds to a PPP data stream between LAC and LNS. Both control
messages and PPP data packets are transmitted in the tunnels.
L2TP uses Hello packets to check the connectivity of a tunnel. LAC and LNS forward
Hello packets to peer ends at regular intervals. If no response to Hello packet is
received in a certain period of time, the tunnel is disconnected.
3)
Definitions of control message and data message
There are two kinds of messages in L2TP: control messages and data messages.
Control messages are used for the setup, maintenance and transmission control of
tunnel and session connections, while data messages are for PPP frame encapsulation
and transmission in tunnels. The transmission of control messages is reliable,
delivering flow and congestion control. On the contrary, the transmission of data
2-3
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
messages is unreliable, meaning it lacks mechanisms of retransmission, flow control,
and congestion control.
Control messages and data messages share the same type of packet headers. Tunnel
ID and Session ID are included in L2TP packet header, to identify different tunnels and
sessions. The packets with the same Tunnel ID but different Session IDs will be
multiplexed in the same tunnel. Tunnel ID and Session ID in the packet header are
assigned by peer ends.
IV. Two typical L2TP tunnel modes
The following figure shows the tunnel modes available between remote system or LAC
clients (hosts running L2TP) and LNS:
LAC client
LAC
Internet
PSTN/ISDN
Remote system
LAC
LNS
internet server
LNS
internet server
Frame Relay
or ATM
Figure 2-3 Two typical L2TP tunnel modes
1)
Initiated by remote dial-up user. Remote system dials in LAC via PSTN/ISDN. LAC
sends tunnel setup request to LNS through the Internet. Dial-up users’ addresses
are assigned by LNS. The authentication and accounting of remote dial-up users
can be accomplished either by LAC side as an agent or by LNS side directly.
2)
Initiated directly by LAC users (local users who support L2TP). LAC users can
send tunnel setup request directly to LNS, without requiring an additional LAC
device after the public network address is assigned to LAC users. LAC users’
private network addresses are assigned by LNS.
V. Call setup flow of L2TP tunnel
Typical L2TP application network is as follows:
2-4
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
RADIUS Serv er
RADIUS Serv er
IP netw ork
IP netw ork
PSTN/ISDN
PC
WAN
PC
SecPathA
LAC
SecPathB
LNS
PC
Figure 2-4 Typical L2TP application network
Call setup flow of L2TP tunnel is shown in the following figure:
LAC
PC
LAC
RADIUS Serv er
LNS
LNS
RADIUS Serv er
(1) Call Setup
(2) PPP LCP Setup
(3) PAP or CHAP authentication
(4) access request
(5) access accept
(6) Tunnel establishment
(7) PAP or CHAP authentication
(challenge/response)
(8) authentication passes
(9) user CHAP response, ppp
negotiation parameter
(10) access request
(11) access accept
(12) CHAP authentication tw ice(challenge/response)
(15) authentication passes
(13) access request
(14) access accept
Figure 2-5 Call setup flow of L2TP channel
The following is the call setup process using L2TP tunnel:
1)
The PC at user side initiates setup request;
2)
The PC and LAC equipment negotiate PPP LCP parameters;
3)
LAC performs PAP or CHAP authentication based on the information provided by
the PC;
2-5
Operation Manual – VPN
H3C SecPath Series Security Products
4)
Chapter 2 L2TP Configuration
LAC sends access request including VPN user's name and password to RADIUS
server for authentication;
5)
RADIUS server authenticates this user and sends back access accept, such as
LNS address, after authentication is passed successfully; LAC is ready for
initiating a new tunnel request;
6)
LAC initiates a tunnel request to the LNS address sent back by RADIUS server;
7)
LAC informs LNS of “CHAP challenge” information, LNS sends back CHAP
response and its own CHAP challenge, and LAC sends back CHAP response;
8)
Authentication passes successfully;
9)
LAC transmits the information of CHAP response, response identifier and PPP
negotiation parameters to LNS;
10) LNS sends the access request to RADIUS server for authentication;
11) RADIUS server authenticates this access request and sends back a response if
authentication is successful;
12) If local mandatory CHAP authentication is configured at LNS, LNS will
authenticate the VPN user by sending CHAP challenge and the VPN user at PC
sends back responses;
13) LNS resends this access request to RADIUS for authentication;
14) RADIUS server re-authenticates this access request and sends back a response if
authentication is successful;
15) The authentication passes and the VPN user can use the internal resources of the
enterprise.
2.2 LAC Configuration
Concerning L2TP configuration, configuration of LAC side differs from that of LNS side.
This section mainly covers the configuration of LAC side. In configuration task list,
L2TP must be enabled and L2TP group must be created before any other functions can
be configured. For detailed introduction to related PPP configuration commands, refer
to the chapters and sections for them.
Configuration tasks at LAC side include:
z
Enable L2TP (required)
z
Create L2TP group (required)
z
Set the condition triggering L2TP tunnel setup request and LNS addresses
(required)
z
Set local name (optional)
z
Set tunnel authentication and password (optional)
z
Configure AVP hiding (optional)
z
Set Hello interval in the tunnel.(optional)
z
Set user name and password and configure user authentication (required)
z
Disconnect Tunnel by force (optional)
z
Enable/disable the flow control function of the tunnel (optional)
2-6
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
z
Set L2TP session idle-timeout timer (optional)
z
Configure the tunnel-hold function of L2TP (optional)
z
Set the LAC to function as client (optional)
2.2.1 Enabling L2TP
Only after L2TP is enabled can L2TP functions on the firewall work normally. If L2TP is
disabled, the firewall cannot provide related functions even if parameters of L2TP have
been configured.
These configurations are compulsory on LAC side.
Perform the following configuration in system view.
Table 2-1 Enable/disable L2TP
Operation
Command
Enable L2TP
l2tp enable
Disable L2TP
undo l2tp enable
By default, L2TP is disabled.
Note:
When the tunnel is established or cannot be established due to authentication failure,
disable the L2TP function at the LAC side and then reenable it, if the tunnel cannot be
established:
z
When the LAC serves as client end, you need to execute the undo l2tp-auto-client
enable command in virtual template interface view at the LAC side, and then
execute the l2tp-auto-client enable command to establish the tunnel.
z
When the LAC does not serve as client end, that is, when a remote user dials to the
LAC, new connection should be set up at the remote end to establish the tunnel.
2.2.2 Creating L2TP Group
L2TP group needs to be created in order to fulfill related parameter configurations of
L2TP. It allows you not only to configure L2TP functions as needed but also to
implement one-to-one and one-to-many network applications between LAC and LNS.
L2TP groups are numbered separately on LAC and LNS, so LAC and LNS only need to
keep consistent in the configurations of the involved L2TP groups (such as remote
name of tunnel and start L2TP and LNS address).
These configurations are compulsory on LAC side.
2-7
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
Perform the following configuration in system view.
Table 2-2 Create/delete L2TP group
Operation
Command
Create L2TP group
l2tp-group group-number
Delete L2TP group
undo l2tp-group group-number
After a L2TP group is created, other configurations related to the L2TP group can be
performed in L2TP group view, for example, name of peer end, condition triggering
L2TP tunnel setup request and LNS address.
By default, no L2TP group is created.
2.2.3 Setting Condition Triggering L2TP Tunnel Setup Request and LNS
Address
A firewall will not send L2TP Tunnel setup request to some other devices (such as
firewall, router or LNS server) unless certain conditions are met. By configuring
decision making rule based on user information and specifying IP address of LNS, you
may allow the firewall to determine whether a user is a VPN user and initiate
connection with the LNS. Up to five LNS addresses can be configured, meaning LNS
backup is allowed. In normal operations, local firewall (LAC) sends Tunnel setup
request to the peer end (LNS) in the order in which LNS addresses are configured until
some LNS accepts the request. This LNS becomes the peer end of L2TP tunnel. An
L2TP Tunnel setup request can be triggered by full user name and domain name.
Perform the following configuration in L2TP group view.
Table 2-3 Set condition triggering L2TP Tunnel setup request and LNS address
Operation
Command
Configure to check if the user is VPN
user and set IP address of LNS
start l2tp { ip ip-addr [ ip ip-addr] [ ip
ip-addr] ... } { domain domain-name |
fullusername user-name }
Cancel the Tunnel setup request
configuration
undo start
The parameters above have no default values and they can be configured as needed.
But at least one triggering condition must be configured for initiating L2TP Tunnel setup
request.
2-8
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
When the L2TP LAC starts a L2TP tunnel connection, the system checks whether the
L2TP group specified according to the complete user name exists. If the system does
not find the required L2TP group, the system continues to search for the required L2TP
group according to the domain name.
Note:
z
If multiple LNSs are configured, because the PPP timeout time of different clients is
different, connections may not be set up between the LAC and the backup LNSs. So,
you are recommended to configure two LNSs at most.
z
A firewall can serve both as LAC and LNS simultaneously. When a firewall serves
both as a LAC and an LNS, different usernames should be used; otherwise, L2TP
may function abnormally.
2.2.4 Setting Tunnel Name
A user can configure local tunnel name on LAC side. The tunnel name of LAC side
must keep in line with the remote name of tunnel configured on LNS side.
These configurations are optional on LAC side.
Perform the following configuration in L2TP group view.
Table 2-4 Set local Tunnel name
Operation
Command
Set local Tunnel name.
tunnel name name
Restore the default local Tunnel name.
undo tunnel name
By default, local tunnel name is the hostname of the firewall.
Note:
To establish a tunnel, an LNS should select a local L2TP group according to the tunnel
name of the LAC. If all L2TP groups share the same tunnel name, the LNS selects a
group that first meets the requirements to establish a tunnel. To establish multiple
tunnels, you need to set different tunnel names for the L2TP groups.
2-9
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
2.2.5 Setting Tunnel Authentication and Password
As needed, a user can decide whether to start tunnel authentication before creating
tunnel connection. Tunnel authentication request can be sent by either LAC side or
LNS side. If one end of a tunnel starts tunnel authentication, the other end must also
start tunnel authentication in order to set up the tunnel connection. In addition, both
ends must use the same password, which cannot be void. Otherwise, the local end will
disconnect the tunnel automatically. If tunnel authentication is disabled on both ends,
the consistency of password will be insignificant.
These configurations are optional on LAC side.
Perform the following configuration in L2TP group view.
Table 2-5 Set Tunnel authentication and authentication password
Operation
Command
Start Tunnel authentication.
tunnel authentication
Disable Tunnel authentication.
undo tunnel authentication
Set the password of Tunnel
authentication.
tunnel password { simple | cipher }
password
Restore the password of Tunnel
authentication to the default.
undo tunnel password
By default, tunnel authentication is enabled, with password of tunnel authentication
being null. For the sake of tunnel security, it is not suggested to disable tunnel
authentication.
2.2.6 Configuring AVP Hiding
L2TP uses attribute value pair (AVP) to transfer and negotiate some parameter
attributes. By default, AVP is transferred in simple text. For security, users can hide AVP
data in transmission by using the following configuration. AVP hiding only works when
both of the two ends use tunnel authentication.
These configurations are optional on LAC side.
Perform the following configuration in L2TP group view.
Table 2-6 Configure AVP hiding
Operation
Command
Enable AVP hiding
tunnel avp-hidden
Restore the default AVP transfer mode
undo tunnel avp-hidden
By default, AVP is transferred in simple text.
2-10
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
2.2.7 Setting Hello Interval in Tunnel
In order to check the connectivity of the tunnel between LAC and LNS, LAC and LNS
send Hello packets to each other periodically and the receiver will respond upon the
receipt of the packets. If LAC or LNS does not receive response from the peer end in a
specified interval, it will resend Hello packet and will regard the L2TP tunnel connection
has been disconnected if receiving no response after making three transmission
attempts. In this case, LAC and LNS need to set up a new tunnel connection.
This configuration is optional on LAC side.
Perform the following configuration in L2TP group view.
Table 2-7 Set Hello interval in a tunnel
Operation
Command
Set Hello interval in a tunnel.
tunnel timer hello hello-interval
Restore the default Hello interval.
undo tunnel timer hello
By default, Hello interval is 60 seconds. If this configuration is not performed on LAC
side, LAC will send Hello packet to the peer end at intervals of the default value.
2.2.8 Setting Username, Password and Local User Authentication
If you have configured local authentication when configuring AAA authentication on
LAC side, you also need to configure local username and password on this side.
LAC performs user authentication to determine whether a user is a valid VPN user by
comparing remote dial-in username and password with usernames and passwords
registered at the local end. It originates Tunnel setup request only upon successful
authentication. Otherwise, the user will be diverted to other kinds of services.
These configurations are compulsory on LAC side.
I. Configuring user name and password
Table 2-8 Configure a username and password
Operation
Command
Configure a user name and password (in
system view).
local-user username
Delete the current setting (in system
view).
undo local-user username
Configure local user password (in local
user view).
password { simple | cipher } password
By default, no local username and password are configured at the LAC side.
2-11
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
II. Configuring PPP user authentication mode
Perform the following configuration in virtual template interface view.
Table 2-9 Configure/Cancel PPP user authentication mode
Operation
Command
Configure a PPP user authentication
mode.
ppp authentication-mode { chap |
pap } [ call-in ] [ domain isp-name ]
Disable PPP user authentication.
undo ppp authentication-mode
By default, the user authentication is not configured. The interface where you configure
local authentication must be the one connected to users.
III. Configuring a PPP domain user and an authentication scheme
Table 2-10 Configure a PPP domain user and an authentication scheme
Operation
Command
Create an ISP domain and enter its view
(in system view).
domain { isp-name | default { disable |
enable isp-name } }
Delete the specified ISP domain (in
system view.
undo domain isp-name
Configure the local authentication
scheme for the PPP domain user (in ISP
domain view).
scheme local
2.2.9 Disconnecting an L2TP Connection
A connection can be disconnected for one of these reasons: no user is present, fault
occurs on the network, or the administrator requests to do so.
Both LAC side and LNS side can start tunnel disconnection. After a tunnel is
disconnected, the control connection and sessions on it are cleared. This tunnel can be
set up when a new user dials in.
These configurations are optional on LAC side.
Perform the following configuration in user view.
2-12
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
Table 2-11 Disconnect a connection
Operation
Command
Disconnect a tunnel
reset l2tp tunnel { name remote-name | id tunnel-id }
Disconnect a session
reset l2tp session session-id
Disconnect a user
reset l2tp user user-name user-name
2.2.10 Setting Flow Control Function of Tunnel
This configuration can enable/disable the flow control function on a tunnel.
Perform the following configuration in L2TP group view.
Table 2-12 Set flow control function of a tunnel
Operation
Command
Enable flow control function of a tunnel.
tunnel flow-control
Disable flow control function of a tunnel.
undo tunnel flow-control
By default, the flow control function of tunnels is disabled.
2.2.11 Setting the L2TP Session Idle-Timeout Timer
An L2TP session is disconnected automatically if the session is idle or no data is
transmitted or received on it for a specified period of time. You may set a session
idle-timeout timer to specify this idle period. This period can be 0 seconds, that is, never
expired.
Table 2-13 Set the L2TP session idle-timeout timer
Operation
Command
Set the L2TP session idle-timeout timer
session idle-time seconds
Disable the L2TP session idle-timeout timer
undo session idle-time
By default, L2TP session idle-timeout timer never expires.
2.2.12 Configuring the Tunnel-Hold Function of L2TP
Normally, the LAC sets up a tunnel with the LNS only when receiving an L2TP session
request from a PPP user. This tunnel is automatically torn down after all PPP sessions
are disconnected.
2-13
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
For some applications that require fast connection setup, however, a tunnel must be
available beforehand so that the system can set up a session immediately after
receiving a PPP session request. To this end, the LAC and the LNS must always
maintain a tunnel connection even when no session is present on it.
Perform the following configuration in L2TP group view.
Table 2-14 Configure the tunnel-hold function of L2TP
Operation
Command
Enable the tunnel-hold function of L2TP
tunnel keepstanding
Disable the tunnel-hold function of L2TP
undo tunnel keepstanding
By default, the tunnel-hold function of L2TP is disabled.
Note:
To have the tunnel-hold function take effect, you must configure it on both LAC and
LNS.
After you configure the tunnel-tunnel function of L2TP, you can execute the start l2tp
tunnel command to start a tunnel connection.
Perform the following configuration in L2TP group view.
Table 2-15 Start an L2TP tunnel connection
Operation
Command
Start an L2TP tunnel connection
start l2tp tunnel
2.2.13 Setting LAC to Function as Client
Normally, the L2TP client is the host that dials to the LAC, where the connection
between the user and the LAC is always PPP connection.
If the LAC is functioning as the client, the connection between the host and the LAC can
be an IP connection allowing the LAC to forward the IP packets from the host to the
LNS. This is equivalent to creating a virtual PPP user associated with multiple actual
users on the LAC and maintaining a permanent connection for it. The IP packets of all
these actual users are forwarded to the LNS through this virtual user.
To use the LAC as the client, you must add the following configurations in addition to
other LAC configurations:
2-14
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
z
Create a virtual template interface
z
Configure the parameters of the virtual template interface, including IP address,
PPP authentication mode, and username and password for PPP authentication
z
Enable the LAC client to set up L2TP tunnel
Note:
When the LAC is functioning as the L2TP client, you must set the L2TP session
idle-timeout timer to 0 or disable it, preventing the session of the virtual user is
disconnected when no data is transmitted or received.
I. Creating a virtual template interface
Perform the following configuration in system view.
Table 2-16 Create/delete a virtual template interface
Operation
Command
Create a virtual template interface
interface virtual-template
virtual-template-number
Delete a virtual template interface
undo interface virtual-template
virtual-template-number
II. Configuring the parameters of the virtual template interface
Perform the following configuration in virtual template interface view.
Table 2-17 Configure the parameters of the virtual template interface
Operation
Command
Assign an IP address to the virtual
template interface
ip address { address mask |
ppp-negotiate | unnumbered
interface interface-type
interface-number }
Configure a PPP authentication mode
ppp authentication-mode { pap |
chap }
Configure the username for CHAP
authentication
ppp chap user user-name
Configure the password for CHAP
authentication
ppp chap password { simple | cipher }
password
Configure the username and password
for PAP authentication
ppp pap local-user user-name
password { simple | cipher } password
2-15
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
III. Enabling/disabling the LAC client to set up L2TP tunnel
Perform the following configuration in virtual template interface view.
Table 2-18 Enable/disable the LAC client to set up L2TP tunnel
Operation
Command
Enable the LAC client to set up L2TP tunnel
l2tp-auto-client enable
Disable the LAC client to set up L2TP tunnel
undo l2tp-auto-client enable
By default, the LAC client is disabled to set up L2TP tunnel.
2.3 LNS Configuration
In LNS configuration task list, L2TP must be enabled and L2TP group must be created
before any other functions can be configured. For detailed introduction to related
commands of PPP and Virtual-Template, refer to corresponding chapters and sections.
The major configuration tasks on LNS side include:
z
Enable L2TP (required)
z
Enable L2TP multi-domain function (optional)
z
Create L2TP group (required)
z
Create virtual template (required)
z
Set the parameters for call receiving (required)
z
Set local name (optional)
z
Set tunnel authentication and password (optional)
z
Set the transmission mode of AVP data (optional)
z
Set Hello interval in the tunnel (optional)
z
Configure mandatory local CHAP authentication (optional)
z
Configure mandatory LCP renegotiation (optional)
z
Set local address (required) and assigned address pool (optional)
z
Set user name and password and configure user authentication (optional)
z
Disconnect tunnel by force(optional)
z
Set the flow control function of tunnel (optional)
z
Configure the timeout time of L2TP session (optional)
2.3.1 Enabling L2TP
Only after L2TP is enabled can L2TP functions on the firewall work normally. If L2TP is
disabled, the firewall cannot provide related functions even if parameters of L2TP have
been configured.
These configurations are compulsory on LNS side.
Perform the following configuration in system view.
2-16
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
Table 2-19 Enable/disable L2TP
Operation
Command
Enable L2TP.
l2tp enable
Disable L2TP.
undo l2tp enable
By default, L2TP is disabled.
2.3.2 Enabling L2TP Multi-Domain Function
Only when L2TP multi-domain function is enabled can the firewall perform LNS for
several enterprises. L2TP multi-domain function enriches VPN networking. In section
2.5.3 “L2TP Multi-Domain Networking”, a brief configuration procedure is described.
In L2TP multi-domain applications, these configurations are compulsory at LNS side.
Perform the following configuration in system view.
Table 2-20 Enable/disable L2TP multi-domain function
Operation
Command
Enable L2TP multi-domain function.
l2tpmoreexam enable
Disable L2TP multi-domain function.
undo l2tpmoreexam enable
By default, L2TP multi-instance function is disabled.
2.3.3 Creating L2TP Group
L2TP group needs to be created in order to fulfill related parameter configurations of
L2TP. It allows you not only to configure L2TP functions on the firewall as needed but
also to implement one-to-one and one-to-many network applications between LAC and
LNS easily. L2TP groups are numbered separately on LAC and LNS, so LAC and LNS
only need to keep consistent in the configurations of the involved L2TP groups such as
remote name of tunnel, start L2TP and LNS address.
These configurations are compulsory on LNS side.
Perform the following configuration in system view.
2-17
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
Table 2-21 Create/delete L2TP group
Operation
Command
Create L2TP group.
l2tp-group group-number
Delete L2TP group.
undo l2tp-group group-number
After L2TP group is created, other configurations related to the L2TP group can be
performed in L2TP group view, for example, local name and remote name of tunnel.
By default, no L2TP group is created.
2.3.4 Creating Virtual Template
Virtual template is mainly used to configure parameters of virtual interface created
dynamically by the firewall in operation.
These configurations are compulsory on LNS side.
Perform the following configuration in system view.
Table 2-22 Create/delete virtual template
Operation
Command
Create a virtual template.
interface virtual-template virtual-template-number
Delete the virtual template.
undo interface virtual-template
virtual-template-number
By default, no virtual template is created.
Note:
If the IP address unnumbered attribute is configured on a virtual template interface, and
the interface is engaged in a certain service, the L2TP function on this interface may
function abnormally.
2.3.5 Setting Parameters for Call Receiving
LNS can adopt different virtual template interfaces for receiving tunnel setup request
from different LACs. When receiving a tunnel setup request from an LAC, LNS needs to
check that the name of LAC is a valid remote name of tunnel before allowing it to create
the tunnel.
These configurations are compulsory on LNS side.
2-18
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
Perform the following configuration in L2TP group view.
Table 2-23 Set parameters for call receiving
Operation
Command
Set remote name of tunnel (L2TP group
not being 1).
allow l2tp virtual-template
virtual-template-number remote
remote-name [ domain domain-name ]
Set remote name of tunnel (L2TP group
being 1).
allow l2tp virtual-template
virtual-template-number [ remote
remote-name ] [ domain domain-name ]
Remove remote name of tunnel
undo allow
When the group number of L2TP is 1 (the default L2TP group number), you do not need
to specify remote-name. If remote-name is specified in L2TP group view 1, L2TP group
1 will not be regarded as the default L2TP group.
Note:
z
Only L2TP group 1 can be set as default group.
z
Any device can initiates a tunnel setup request when L2TP group 1 (the default
group) is set.
z
The start command and the allow command are mutually exclusive. After one is
configured, another one goes invalid automatically.
z
When PPPoE client is used to trigger the tunnel between the LAC and LNS, you are
recommended to set the MTU value for the virtual template interface at the LNS side
to 1480 bytes.
z
A firewall can serve both as LAC and LNS simultaneously. When a firewall serves
both as a LAC and an LNS, different usernames should be used; otherwise, L2TP
may function abnormally.
2.3.6 Setting Local Name
A user can configure local tunnel name on LNS side.
These configurations are optional on LNS side.
Perform the following configuration in L2TP group view.
2-19
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
Table 2-24 Set local name
Operation
Command
Set local name.
tunnel name name
Restore the default value of local name.
undo tunnel name
By default, local name is the hostname of the firewall.
2.3.7 Setting Tunnel Authentication and Password
As needed, a user can decide whether to start tunnel authentication before creating
tunnel connection. Tunnel authentication request can be sent by either LAC side or
LNS side. If one end of a tunnel starts tunnel authentication, the other end must also
start tunnel authentication in order to set up the tunnel connection. In addition, both
ends must use the same password, which cannot be void. Otherwise, the local end will
disconnect the tunnel automatically. If tunnel authentication is disabled on both ends,
the consistency of password will be insignificant.
These configurations are optional on LNS side.
Perform the following configuration in L2TP group view.
Table 2-25 Set tunnel authentication and authentication password
Operation
Command
Start tunnel authentication.
tunnel authentication
Disable tunnel authentication.
undo tunnel authentication
Set a password for tunnel
authentication.
tunnel password { simple | cipher }
password
Remove the password for tunnel
authentication.
undo tunnel password
By default, tunnel authentication is enabled, with the password being null. For the sake
of tunnel security, you are not recommended to disable tunnel authentication.
2.3.8 Setting Transfer Mode of AVP Data
AVP is adopted in L2TP protocol to move and negotiated some attribute parameters of
L2TP. By default, AVP is transferred in simple text. For security, users can hide these
AVP in transmission by using the following configuration. The function of hidden VAP
only works when both of the two ends use tunnel authentication.
These configurations are optional on LNS side.
Perform the following configuration in L2TP group view.
2-20
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
Table 2-26 Set the transfer mode of AVP data
Operation
Command
Configure hidden AVP data for transfer.
tunnel avp-hidden
Restore default transfer mode of AVP.
undo tunnel avp-hidden
By default, AVP is transferred in simple text.
2.3.9 Setting Hello Interval in Tunnel
In order to check the connectivity of the tunnel between LAC and LNS, LAC and LNS
send Hello packets to each other periodically and the receiver will respond upon the
receipt of the packets. If LAC or LNS does not receive response from the peer end in a
specified interval, it will resend Hello packet and will regard the L2TP tunnel connection
has been disconnected if receiving no response after making three transmission
attempts. In this case, LAC and LNS need to set up a new tunnel connection.
This configuration is optional on LNS side.
Perform the following configuration in L2TP group view.
Table 2-27 Set Hello interval
Operation
Command
Set Hello interval.
tunnel timer hello hello-interval
Restore the default value of Hello interval.
undo tunnel timer hello
By default, Hello interval is 60 seconds. If this configuration is not performed on LNS
side, LNS will adopt this default value to send Hello packet to the peer end periodically.
2.3.10 Enabling Mandatory Local CHAP Authentication
After LAC performs agent authentication on a user, LNS can authenticate the user
again. The user therefore undergoes authentication twice: once on LAC side and once
on LNS side. Only after both the two authentications succeed, can L2TP tunnel be
created.
In an L2TP network, LNS side authenticates users in three ways: agent authentication,
mandatory CHAP authentication, and LCP re-negotiation.
Among these three authentication approaches, LCP re-negotiation is of the first priority.
If both LCP re-negotiation and mandatory CHAP authentication are configured on LNS
side, L2TP will choose the former, adopting the authentication mode configured in the
associated virtual template.
2-21
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
If only CHAP authentication is configured, LNS will perform CHAP authentication on
users.
To perform mandatory CHAP authentication on LNS side, you must configure
username, password and user authentication and enable AAA on this side. Mandatory
local CHAP authentication is optional on LNS side.
Perform the following configuration in L2TP group view.
Table 2-28 Enable mandatory local CHAP authentication
Operation
Command
Enable mandatory local CHAP authentication.
mandatory-chap
Disable local CHAP authentication.
undo mandatory-chap
If neither LCP re-negotiation nor mandatory CHAP authentication is configured, LNS
will perform agent authentication on the user. In this case, LAC sends LNS all
authentication information received from the user as well as authentication mode
configured on LAC side. If you do not configured authentication mode for the virtual
template, the LNS side will accept the authentication result on LAC side.
When LNS adopts agent authentication, session is allowed to be created if
authentication mode configured in virtual template is PAP and the authentication
succeeds. If authentication mode configured in virtual template is CHAP and that
configured on LAC side is PAP, authentication fails and session cannot be correctly
created as the CHAP authentication level demanded by LNS is higher than PAP
authentication supplied by LAC.
Local end does not perform mandatory CHAP authentication by default.
2.3.11 Forcing LCP to Re-negotiate
For NAS-Initialized VPN, the user first performs PPP negotiation with NAS when PPP
session starts. If the negotiation passes, NAS initializes L2TP tunnel connection, and
transmits user information to LNS so that LNS can judge whether the user is legal or not
according to the received agent authentication information,
But in some cases (for example, authentication and accounting need performing on
LNS side simultaneously), required re-negotiation needs to be created between LNS
and the user, and agent authentication information on NAS side will be ignored.
The configuration of mandatory LCP re-negotiation is optional on LNS side.
Perform the following configuration in L2TP group view.
2-22
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
Table 2-29 Enable/disable mandatory LCP re-negotiation
Operation
Command
Enable mandatory LCP re-negotiation.
mandatory-lcp
Disable mandatory LCP re-negotiation.
undo mandatory-lcp
By default, LCP re-negotiation is not performed.
Despite LCP re-negotiation is enabled, LNS will not perform authentication on the user
if authentication is not configured in the associated virtual template. In this case, the
user is only authenticated once on LAC side, and the address from the global address
pool is assigned to the client directly.
2.3.12 Setting Local Address and Assigning Address Pool
After the L2TP tunnel connection between LAC and LNS is created, LNS should assign
IP addresses for VPN users from address pool. Before address pool is specified, you
must use the ip pool command in system view or domain view to define an address
pool. For detailed description about the ip pool command, refer to the “Security” part of
this manual. If LNS adopts agent authentication or mandatory CHAP authentication,
the system uses the address pool configured in domain view for address assignment; if
LNS adopts mandatory LCP re-negotiation, the system uses the domain address pool
for address assignment; if LNS adopts LCP re-negotiation and does not authenticate
users, and the system uses global address pool for address assignment.
On LNS side, local address configuration is required and address pool assignment is
optional.
Perform the following configuration in virtual template view.
Table 2-30 Set local address and assigned address pool
Operation
Command
Set local IP address.
ip address X.X.X.X netmask
Remove the local IP address.
undo ip address X.X.X.X netmask
Specify an address pool for remote
address assignment.
remote address { pool pool-number |
X.X.X.X }
Delete the address pool for remote
address assignment.
undo remote address
If you do not assign a value to the pool-number parameter behind the keyword pool
when specifying an address pool, the system will use the default address pool for
assignment.
2-23
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
By default, addresses will be assigned to the peer end from address pool 0 (default
address pool).
2.3.13 Setting Username, Password and User Authentication
On LNS side, if mandatory CHAP authentication has been configured, it needs to
configure local registered username and password on LNS side.
LAC performs user authentication to determine whether a user is a valid VPN user by
comparing remote dial-in username and password with usernames and passwords
registered at the local end. If the authentication passes, the VPN user is allowed to
communicate with LNS; if it fails, L2TP will be notified to clear the L2TP connection.
These configurations are optional on LNS side. For more information on how to
configure them, refer to the section 2.2.8 “Setting Username, Password and Local
User Authentication.”
2.3.14 Disconnecting an L2TP Connection
A connection can be disconnected for one of these reasons: no user is present, fault
occurs on the network, or the administrator requests to do so.
Both LAC side and LNS side can start disconnection. After a tunnel is disconnected, the
control connection and sessions on it are cleared. This tunnel can be set up when a
new user dials in.
These configurations are optional on LNS side.
Perform the following configuration in user view.
Table 2-31 Disconnect a connection by force
Operation
Command
Disconnect a tunnel
reset l2tp tunnel { name remote-name | id tunnel-id }
Disconnect a session
reset l2tp session session-id
Disconnect a user
reset l2tp user-name user-name
2.3.15 Enabling/Disabling Flow Control Function of Tunnel
This configuration can enable/disable the simple flow control function on a tunnel.
These configurations are optional on LAC side.
Perform the following configuration in L2TP group view.
2-24
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
Table 2-32 Enable/disable flow control function of a tunnel
Operation
Command
Enable flow control function of a tunnel
tunnel flow-control
Disable flow control function of a tunnel
undo tunnel flow-control
By default, the flow control function of tunnels is disabled.
2.3.16 Setting the L2TP Session Idle-Timeout Timer
An L2TP session is disconnected automatically if the session is idle or no data is
transmitted or received on it for a specified period of time. You may set a session
idle-timeout timer to specify this idle period. This period can be 0 seconds, that is, never
expired.
Perform the following configuration in L2TP group view.
Table 2-33 Set the L2TP session idle-timeout timer
Operation
Command
Set the L2TP session idle-timeout timer
session idle-time seconds
Disable the L2TP session idle-timeout timer
undo session idle-time
By default, L2TP session idle-timeout timer never expires.
2.3.17 Configuring EAD Support for L2TP
With this feature enabled, the endpoint admission defense (EAD) server will implement
security authentication on PPP users that have passed the access authentication. The
PPP users can access network resources normally after passing the security
authentication; otherwise, they can only access resources in the isolation zone.
Table 2-34 Configure PPP access control
Operation
Command
Description
Enter VT interface view
interface
virtual-template number
—
Enable PPP access
control
ppp access-control
enable
Required
Configure the packet-filter
fragment matching mode
for PPP users on the VT
interface
ppp access-control
match-fragments
{ normally | exactly }
2-25
Disabled by default
Optional
The fragment matching
mode defaults to
normally.
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
Operation
Command
Display access control
statistics of PPP users on
the VT interface
display ppp
access-control
{ interface type number }
Description
—
2.4 Displaying and Debugging L2TP
After performing the above configuration tasks, execute display commands in any view
to view the running status of L2TP configurations, and to verify the configuration effect.
The debugging commands can be used in user view.
Table 2-35 Display and debug L2TP
Operation
Command
Display information about the current
L2TP users
display l2tp user
Display information about the current
L2TP tunnels
display l2tp tunnel
Display information about the current
L2TP sessions
display l2tp session
Enable all L2TP information debugging
debugging l2tp all
Disable all L2TP information debugging
undo debugging l2tp all
Enable L2TP control packet debugging
debugging l2tp control
Disable L2TP control packet debugging
undo debugging l2tp control
Enable PPP packet debugging
debugging l2tp dump
Disable PPP packet debugging
undo debugging l2tp dump
Enable L2TP error debugging
debugging l2tp error
Disable L2TP error debugging
undo debugging l2tp error
Enable L2TP event debugging
debugging l2tp event
Disable L2TP event debugging
undo debugging l2tp event
Enable hidden AVP debugging
debugging l2tp hidden
Disable hidden AVP debugging
undo debugging l2tp hidden
Enable L2TP payload debugging
debugging l2tp payload
Disable L2TP payload debugging
undo debugging l2tp payload
Enable L2TP time stamp debugging
debugging l2tp time-stamp
Disable L2TP time stamp debugging
undo debugging l2tp timestamp
2-26
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
2.5 L2TP Configuration Example
Both NAS and user end can initiate L2TP calls. They are illustrated separately as
follows.
2.5.1 NAS-initialized VPN Networking
I. Network requirements
A VPN user access company headquarters following the procedure below:
z
User accesses the network in dialup mode.
z
NAS performs authentication on this user, and then originates a tunnel setup
request to LNS if it is a VPN user.
After establishing the tunnel with LNS, NAS sends packets to LNS, providing the
z
negotiated information between NAS and VPN users.
LNS decides whether to accept the connection according to the pre-negotiated
z
information.
User communicates with the company headquarters by using the tunnel between
z
NAS and LNS.
II. Network diagram
Internet
Async2
PSTN/ISDN
Headquarters
tunnel
NAS
VPN user
LAC
LNS
Figure 2-6 Network diagram for NAS-Initialized VPN
III. Configuration procedure
1)
Configuration at user side
At the user end, type user name vpdnuser, password Hello and dialup number 170 in
dialup network window. Then type user name username, password userpass for
RADIUS authentication in dialup terminal window.
2)
Configuration at NAS side
# On NAS, set the dial-in number to 170.
# On RADIUS access server, configure a VPN user with user name username and
password userpass, and set IP address for the corresponding LNS device (In this
example, IP address of the serial port connected with the tunnel at LNS side is
202.38.160.2.).
# Set local device name to LAC, adopt tunnel authentication, set tunnel authentication
password to tunnelpwd.
3)
LNS configuration
2-27
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
# Set username and password (consistent with the configuration at user side).
[H3C] local-user vpdnuser
[H3C-luser-vpdnuser] password simple Hello
[H3C-luser-vpdnuser] service-type ppp
# Perform local authentication on VPN users.
[H3C] domain system
[H3C-isp-system] scheme local
[H3C-isp-system] ip pool 1 192.168.0.2 192.168.0.100
# Enable L2TP and set an L2TP group.
[H3C] l2tp enable
[H3C] l2tp-group 1
# Configure a virtual template.
[H3C] interface virtual-template 1
[H3C-virtual-template1] ip address 192.168.0.1 255.255.255.0
[H3C-virtual-template1] ppp authentication-mode chap domain system
[H3C-virtual-template1] remote address pool 1
# Configure local name and remote name of the tunnel at LNS side.
[H3C] l2tp-group 1
[H3C-l2tp1] allow l2tp virtual-template 1 remote LAC
# Enable tunnel authentication and set the password for it.
[H3C-l2tp1] tunnel authentication
[H3C-l2tp1] tunnel password simple tunnelpwd
2.5.2 Client-initialized VPN Networking
I. Network requirements
A VPN user accesses the headquarters following the procedure below:
It first accesses the Internet, and then originates a tunnel setup request to LNS.
After LNS accepts this connection setup request, VPN establishes a virtual tunnel with
LNS.
The traffic between the user and headquarters travels along the tunnel between the
VPN user and LNS.
2-28
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
II. Network diagram
SecPath
PSTN
Headquarters
Internet
LNS
NAS
VPN user
Tunnel
Figure 2-7 Network diagram for Client-Initialized VPN
III. Configuration procedure
1)
Configuration at user side
Make sure that the user-side host is installed with L2TP client software, WinVPN Client
for example, and the user is connected to the Internet through a dial-up link before
proceeding to perform the following configuration tasks. (The configuration procedure
depends on the installed client software).
# Set VPN user name to vpdnuser and password Hello at user side.
# Set IP address of LNS to the Internet interface address of the firewall (In this example
IP address of the serial port connected with tunnel at LNS side is 202.38.160.2).
# Modify connection attributes. Set the protocol to L2TP, encryption attribute to user
defined. Choose CHAP authentication for tunnel authentication, with tunnel password
tunnelpwd.
2)
LNS configuration
# Set username and password (consistent with the configuration at user side).
[H3C] local-user vpdnuser
[H3C-luser-vpdnuser] password simple Hello
[H3C-luser-vpdnuser] service-type ppp
# Perform local authentication on VPN users.
[H3C] domain system
[H3C-isp-system] scheme local
[H3C-isp-system] ip pool 1 192.168.0.2 192.168.0.100
# Enable L2TP and set an L2TP group.
[H3C] l2tp enable
[H3C] l2tp-group 1
# Configure a virtual template.
[H3C] interface virtual-template 1
[H3C-virtual-template1] ip address 192.168.0.1 255.255.255.0
[H3C-virtual-template1] ppp authentication-mode chap domain system
2-29
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
[H3C-virtual-template1] remote address pool 1
# Configure remote name of the tunnel at LNS side.
[H3C] l2tp-group 1
[H3C-l2tp1] allow l2tp virtual-template 1
# Enable tunnel authentication and set the password for it.
[H3C-l2tp1] tunnel authentication
[H3C-l2tp1] tunnel password simple tunnelpwd
2.5.3 L2TP Multi-Domain Networking
I. Network requirements
PC1 belongs to 263.net domain, and PC2 belongs to 163.net domain. Generally, users
cannot directly access the intranet of the enterprises via the Internet. However, by
creating multi-domain-supported VPN, different domain users can obtain IP addresses
with different ranges from LNS, thus can access the resources on the intranet.
II. Network diagram
SecPath1
PC1
SecPath2
Ethernet0/0/0
Ethernet1/0/0
Internet
Tunnel
LAC
WAN
LNS
PC2
Figure 2-8 Network diagram for multi-domain L2TP
III. Configuration procedure
1)
Configuration at user side
Set up a dial network, and accept addresses assigned by the LNS server to users.
On PC1, the user should type the user name vpdn1@263.net and the password 11111
in the dialup terminal window, supposing that the user name and password have been
registered with the LNS.
On PC2, the user should type the user name vpdn2@163.net and the password 22222
in the pop-up Dial Terminal Window, supposing that the user name and password have
been registered with the LNS.
2)
SecPath1 (LAC) configuration
2-30
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
The Ethernet0/0/0 and Ethernet1/0/0 interfaces at LAC end in this example are for user
access. The IP address of the Ethernet0/0/1 interface is 202.38.160.1; that connecting
the tunnel at LNS end is 202.38.160.2.
# Set username and password.
<H3C> system-view
[H3C] local-user vpdn1
[H3C-luser-vpdn1] password simple 11111
[H3C-luser-vpdn1] service-type ppp
[H3C-luser-vpdn1] quit
[H3C] local-user vpdn2
[H3C-luser-vpdn2] password simple 22222
[H3C-luser-vpdn2] service-type ppp
[H3C-luser-vpdn2] quit
# Adopt local authentication.
[H3C] domain 263.net
[H3C-isp-263.net] scheme local
[H3C-isp-263.net] quit
[H3C] domain 163.net
[H3C-isp-163.net] scheme local
[H3C-isp-163.net] quit
# Configure PPPoE server on the Ethernet0/0/0 and Ethernet1/0/0 interfaces.
[H3C] interface Ethernet0/0/0
[H3C-Ethernet0/0/0] pppoe-server bind Virtual-Template 100
[H3C-Ethernet0/0/0] interface Ethernet1/0/0
[H3C-Ethernet1/0/0] pppoe-server bind Virtual-Template 101
# Configure IP address on Ethernet0/0/1
[H3C-Ethernet0/0/0] interface Ethernet0/0/1
[H3C-Ethernet0/0/1] ip address 202.38.160.1 255.255.255.0
# Enable CHAP authentication on the virtual template.
[H3C-Ethernet0/0/1] interface Virtual-Template 100
[H3C-Virtual-Template100] ppp authentication-mode chap domain 263.net
[H3C-Virtual-Template100] interface Virtual-Template 101
[H3C-Virtual-Template101] ppp authentication-mode chap domain 163.net
[H3C-Virtual-Template101] quit
# Set two L2TP groups and configure the relevant attributes.
[H3C] l2tp enable
[H3C] l2tp-group 1
[H3C-l2tp1] tunnel name LAC
[H3C-l2tp1] start l2tp ip 202.38.160.2 domain 263.net
2-31
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
[H3C-l2tp1] l2tp-group 2
[H3C-l2tp2] tunnel name LAC
[H3C-l2tp2] start l2tp ip 202.38.160.2 domain 163.net
# Enable tunnel authentication and set the password for it.
[H3C-l2tp2] tunnel authentication
[H3C-l2tp2] tunnel password simple 12345
[H3C-l2tp2] quit
[H3C] l2tp-group 1
[H3C-l2tp1] tunnel authentication
[H3C-l2tp1] tunnel password simple 12345
3)
SecPath2 (LNS) configuration.
<H3C> system-view
[H3C] l2tp enable
[H3C] l2tpmoreexam enable
# Create two pairs of usernames and passwords.
[H3C] local-user vpdn1
[H3C-luser-vpdn1] password simple 11111
[H3C-luser-vpdn1] service-type ppp
[H3C-luser-vpdn1] quit
[H3C] local-user vpdn2
[H3C-luser-vpdn2] password simple 22222
[H3C-luser-vpdn2] service-type ppp
[H3C-luser-vpdn2] quit
# Create two address pools.
[H3C] domain 163.net
[H3C-isp-163.net] scheme local
[H3C-isp-163.net] ip pool 1 202.38.161.10 202.38.161.100
[H3C-isp-163.net] quit
[H3C] domain 263.net
[H3C-isp-263.net] scheme local
[H3C-isp-263.net] ip pool 1 202.38.162.10 202.38.162.100
[H3C-isp-263.net] quit
# Create two virtual templates.
[H3C]interface virtual-template 1
[H3C-Virtual-Template1] ip address 202.38.161.1 255.255.255.0
[H3C-Virtual-Template1] remote address pool 1
[H3C-Virtual-Template1] ppp authentication-mode chap domain 163.net
[H3C-Virtual-Template1] interface virtual-template 2
[H3C-Virtual-Template2] ip address 202.38.162.2 255.255.255.0
[H3C-Virtual-Template2] remote address pool 1
2-32
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
[H3C-Virtual-Template2] ppp authentication-mode chap domain 263.net
[H3C-Virtual-Template2] quit
# Create two L2TP-groups correspondingly.
[H3C] l2tp-group 3
[H3C-l2tp3] tunnel authentication
[H3C-l2tp3] allow l2tp virtual-template 1 remote LAC domain 163.net
[H3C-l2tp3] tunnel password simple 12345
[H3C-l2tp3] quit
[H3C] l2tp-group 4
[H3C-l2tp4] tunnel authentication
[H3C-l2tp4] allow l2tp virtual-template 2 remote LAC domain 263.net
[H3C-l2tp4] tunnel password simple 12345
If the LSN side requires RADIUS authentication, you simply need to change the AAA
configuration in the configurations described above.
2.5.4 Using LAC as L2TP Client
I. Network requirements
The LAC-side firewall functions as L2TP client, setting up permanent connection with
LNS. All data from the connected private network is forwarded using the connection to
the LNS.
II. Network diagram
LAC
Priv ate
netw ork
10.2.0.0
LNS
VT1:192.168.0.1
Internet
3.3.3.2
SecPathA
Priv ate
netw ork
10.1.0.0
SecPathB
Figure 2-9 Network diagram for using LAC as the L2TP client
III. Configuration procedure
Note:
This scenario describes only the configurations about VPN, assuming that the involved
public addresses and routes are correctly configured.
1)
Configure LAC firewall.
# Set username and password.
2-33
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
[H3C] local-user vpdnuser
[H3C-luser-vpdnuser] password simple Hello
[H3C-luser-vpdnuser] service-type ppp
[H3C-luser-vpdnuser] quit
# Enable L2TP and create an L2TP group.
[H3C] l2tp enable
[H3C] l2tp-group 1
# Configure the local tunnel name and the IP address of LNS.
[H3C-l2tp1] tunnel name LAC
[H3C-l2tp1] start l2tp ip 3.3.3.2 fullusername vpdnuser
# Enable tunnel authentication and set the password.
[H3C-l2tp1] tunnel authentication
[H3C-l2tp1] tunnel password simple tunnelpwd
[H3C-l2tp1] quit
# Configure virtual-template 1.
[H3C] interface virtual-template 1
[H3C-virtual-template1] ip address ppp-negotiate
[H3C-virtual-template1] ppp authentication-mode pap
[H3C-virtual-template1] ppp pap local-user vpdnuser password simple Hello
[H3C-virtual-template1] quit
# Configure static routing to private network 10.1.0.0.
[H3C] ip route-static 10.1.0.0 16 virtual-template 1
2)
Configure LNS firewall.
# Configure username and password.
[H3C] local-user vpdnuser
[H3C-luser-vpdnuser] password simple Hello
[H3C-luser-vpdnuser] service-type ppp
# Configure the Ethernet0/0/1 interface.
[H3C] interface Ethernet0/0/1
[H3C-Ethernet0/0/1] ip address 3.3.3.2 255.255.0.0
[H3C-Ethernet0/0/1] quit
# Configure the domain and address pool.
[H3C] domain system
[H3C-isp-system] scheme local
[H3C-isp-system] ip pool 1 192.168.0.2 192.168.0.10
[H3C-isp-system] quit
# Enable L2TP and set an L2TP group.
[H3C] l2tp enable
2-34
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
[H3C] l2tp-group 1
# Configure virtual template 1.
[H3C] interface virtual-template 1
[H3C-virtual-template1] ip address 192.168.0.1 255.255.255.0
[H3C-virtual-template1] remote address pool 1
[H3C-virtual-template1] ppp authentication-mode pap
[H3C-virtual-template1] quit
# Configure the remote name of the receive tunnel.
[H3C] l2tp-group 1
[H3C-l2tp1] allow l2tp virtual-template 1 remote LAC
# Enable tunnel authentication and set the password.
[H3C-l2tp1] tunnel authentication
[H3C-l2tp1] tunnel password simple tunnelpwd
[H3C-l2tp1] quit
# Configure static routing to private network 10.2.0.0.
[H3C] ip route-static 10.2.0.0 16 virtual-template1
3)
Start L2TP connection
# Start L2TP connection in virtual template interface view on SecPath A.
[H3C] interface virtual-template 1
[H3C-virtual-template1] l2tp-auto-client enable
Note:
LAC-side host and LNS-side host must be the gateways for their connected private
networks respectively.
2.5.5 Complex Network Design
SecPath Series Firewalls can serve as LAC and LNS at the same time, supporting
multiple simultaneous incoming calls. L2TP can receive and originate multiple calls as
long as memory and line resources are available. These complex network
requirements and their configurations can be implemented by referring to above cases.
Pay special attention to the configuration of static route, because many applications are
based on routing to originate calls.
2-35
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 2 L2TP Configuration
2.6 L2TP Troubleshooting
The VPN tunnel setup process is quite complicated; only several common cases are
analyzed here. Before debugging VPN, please confirm that both LAC and LNS are
connected to a public network, and are connected correctly.
Symptom 1: User’s login fails.
Troubleshooting:
Failure causes are as follows:
z
Fail to establish a tunnel because:
1)
On LAC side, LNS addresses are improperly set.
2)
On LNS side (usually is a firewall, or a router), L2TP group that can receive the
remote end of the tunnel is not configured. For details, refer to the description of
the allow command.
3)
Tunnel authentication fails. If authentication is configured, make sure that the
same tunnel authentication password is configured at both sides.
4)
If the local end compulsorily disconnects the connection but the opposite end fails
to receive the “Disconnect” packet due to some network transmission problem,
originating tunnel setup request without delay will fail in this case. The reason is
that both sides cannot detect the disconnected link within certain time, and the
tunnel connections originated by two opposite ends with the same IP address are
not allowed.
z
PPP negotiation fails because :
1)
Error occurs to username or password set on LAC side, or the corresponding
users are not set on LNS side.
2)
LNS cannot assign addresses because the address pool is too small or no
address pool is set at all.
3)
The types of tunnel password authentication are inconsistent. The default
authentication type of VPN connection created by Windows 2000 is MSCHAP. If
the peer end does not support MSCHAP, CHAP is recommended for substitution.
Symptom 2: Data transmission fails. After the connection is established, no data can be
transmitted, for example, the peer end cannot be pinged.
Troubleshooting: Possible causes are as follows:
z
The address set by the user is wrong: Generally, it is up to LNS to assign
addresses, but a user can also designate his own address. If the designated
address and the address assigned by LNS are not in the same network segment,
this problem occurs. It is recommended that LNS assign addresses completely.
z
Network congestion: Congestion occurs to the Internet backbone and packet loss
is serious. L2TP uses User Datagram Protocol (UDP) for transmission. Because
UDP lacks in error control mechanism, applying L2TP on an unstable line will
result in ping failures.
2-36
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 3 GRE Configuration
Chapter 3 GRE Configuration
3.1 Brief Introduction to GRE
I. GRE overview
Generic Routing Encapsulation protocol (GRE) can encapsulate datagrams of some
network layer protocols (such as IP and IPX) and allow these encapsulated datagrams
to be transferred in another network layer protocol (such as IP). GRE is a layer 3 tunnel
protocol of VPN, adopting a technique called Tunnel between protocol layers. Each
tunnel is a virtual point-to-point connection and can be regarded as a virtual interface
only supporting point-to-point connection in actual situation. The interface provides a
tunnel where encapsulated datagrams can be transmitted. And it can also encapsulate
and de-encapsulate datagrams at both ends of the tunnel.
To move in a tunnel, a packet must undergo the processes of encapsulation and
decapsulation, which are illustrated in Figure 3-1:
Nov ell IPX
Protocol
Group1
Nov ell IPX
Protocol
Group2
Internet
SecPath A
Tunnel
SecPathB
Figure 3-1 IPX network interconnection through GRE tunnel
1)
The process of encapsulation
After receiving an IPX packet, the interface connected to Novell group1 first sends it to
IPX for processing. IPX decides how to route it by examining the destination address
field in its IPX header. If IPX finds that the packet should pass the network 1f (virtual
network number of the tunnel) in order to reach the destination, it delivers the packet to
the tunnel interface with the network number of 1f. After receiving the packet, the tunnel
interface performs GRE encapsulation before forwarding it to the IP module for
processing. After the IP header is encapsulated, the packet will be forwarded to the
appropriate network interface according to its destination address and the routing table.
2)
The process of decapsulation
The process of decapsulation is contrary to that of encapsulation. The system
examines the destination address of each IP packet received from the tunnel interface;
if it is this firewall, the system removes the IP header of the packet and sends it to the
GRE module for processing (verifying key, checksum, and serial number of the packet,
etc.). After completing all the works, the GRE module removes the GRE header of the
packet and sends it to the IPX module where it is handled just as a common one.
3-1
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 3 GRE Configuration
When receiving a datagram that requires encapsulating and routing, called payload,
the system first adds a GRE header to the datagram to form a GRE packet. This GRE
packet is then encapsulated into an IP packet, thus allowing the IP layer to take full
charge of the forwarding of the packet. The IP protocol in this particular case is called
Delivery Protocol or Transport Protocol.
The format of an encapsulated tunnel packet is shown as follows:
Delivery Header
(Transport Protocol)
GRE Header
(Encapsulation Protocol)
Payload Packet
(Passenger Protocol)
Figure 3-2 Format of encapsulated tunnel packets
For instance, an IPX Delivery packet encapsulated in IP tunnel is as follows:
IP
GRE
IPX
Passenger Protocol
Encapsulation Protocol
(Carrier Protocol)
Transport Protocol
Figure 3-3 Format of Delivery packets in Tunnel
II. Application scope
GRE mainly provides services below:
1)
Allowing a multi-protocol local network to make transmission through a
single-protocol backbone
Novell IPX
protocol
Group1
IP protocol
Term 1
Novell IPX
protocol
Group2
Internet
Tunnel
SecPathA
SecPathB
IP protocol
Term 2
Figure 3-4 Multi-protocol local network that makes transmission through a
single-protocol backbone
3-2
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 3 GRE Configuration
In the above figure, Group1 and Group2 are the local networks employing the Novell
IPX protocol; Term1 and Term2 are the local networks running IP. By setting up a GRE
tunnel between SecPath A and SecPath B, you can allow Group1 to communicate with
Group2 and Term1 with Term2 without interfering with each other.
2)
Expanding the operating area of networks running hop-limited protocols (such as
IPX)
SecPathA
SecPathB
Tunnel
IP network
IP network
Router
Router
IP network
PC
r
PC
r
Figure 3-5 Expanding network operating area
If the hop count between two terminals in the above figure is more than 15, the two
terminals cannot communicate with each other. By setting up a tunnel across the
network, some hops can be hidden, thus expanding the operating area of the network.
3)
Connecting some discontinuous sub-networks to establish VPN
SecPathA
SecPathB
nov ell
l
IP netw ork
nov ell
VLAN
group 1
group2
Tunnel
Figure 3-6 Tunnel connecting discontinuous sub-networks
Sub-networks group1 and group2 running Novell IPX are in different cities but they can
form a VPN over WAN by using a tunnel.
4)
The use in conjunction with IPsec
GRE Tunnel
IPSec Tunnel
Corporate
intranet
Remote
office
netw ork
Internet
SecPathA
SecPathB
Figure 3-7 GRE-IPsec tunnel application
3-3
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 3 GRE Configuration
As illustrated in the above figure, GRE can encapsulate multicast data and transmit the
data through the GRE tunnel. As provisioned, IPsec can only protect unicast data at
present. When transmitting such multicast data as routing protocol, voice and image in
an IPsec tunnel, you can set up a GRE tunnel, encapsulate the multicast data with GRE,
and then encrypt the encapsulated data using IPsec. Thus, data secrecy in
transmission can be achieved.
In addition, GRE also supports users to select and record identification key of tunnel
interface, and supports the end-to-end check of encapsulated message.
Due to the influence of such factors as encapsulation and decapsulation between GRE
sender and receiver and data increase caused by encapsulation, the use of GRE may
somewhat decrease the data forwarding efficiency of firewalls.
3.2 GRE Configuration
Among all the configuration tasks, virtual tunnel interface must be created first before
other function features can be configured on it. Deleting a virtual tunnel interface
deletes all configurations on it.
GRE configuration tasks include:
z
Create virtual tunnel interface (required)
z
Set encapsulation mode (optional)
z
Specify source end of tunnel (required)
z
Specify destination end of tunnel (required)
z
Set network address of tunnel interface (required)
z
Configure end-to-end verification on both ends of tunnel (optional)
z
Set identification key of tunnel interface (optional)
z
Configure routing via tunnel (optional)
3.2.1 Creating Virtual Tunnel Interface
Virtual tunnel interface should be created so that other parameters of GRE can be
configured on it. These configurations are required to be performed on both ends of the
tunnel.
Perform the following configuration in system view.
Table 3-1 Create virtual tunnel interface
Operation
Command
Create a virtual tunnel interface.
interface tunnel number
Delete a virtual tunnel interface.
undo interface tunnel number
By default, no virtual tunnel interface is created.
3-4
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 3 GRE Configuration
The device adopts distributed structure, on which interfaces are represented in a
three-dimension way, that is, slot/card/port. The parameter slot represents slot number
of the specified universal interface module; card represents the number of the installed
card, which can take on the value of 0 or 1; port represents the number of the specified
interface, ranging from 0 to 1023, but the actual number of created tunnels depends on
the total number of interfaces and available memory.
On creating Tunnel interface, it is recommended that the parameter slot should keep in
line with the slot of source end interface configured by the source command. In other
words, slot number specified by slot is the same as that of the actual physical interface
forwarding GRE packets, thus improving the forwarding efficiency.
3.2.2 Setting Encapsulation Mode
Encapsulation protocol and delivery protocol are to be configured on tunnel interface.
You may choose not to configure them on both ends of the tunnel, but if you do
configure them, make sure to use the same encapsulation mode on both ends (by far,
only GRE is available).
Perform the following configuration in tunnel interface view.
Table 3-2 Set encapsulation mode
Operation
Command
Set encapsulation mode on the tunnel interface.
tunnel-protocol gre
By default, encapsulation protocol is GRE, and delivery protocol is IP.
3.2.3 Specifying Tunnel Source
After the creation of a tunnel interface, the source address of the tunnel, that is, the
actual interface address where GRE packets are forwarded also needs to be specified.
A tunnel is uniquely identified by one source address and one destination address.
These configurations are required on both ends of the tunnel, with the source address
at one end being the destination address at the other end and vice versa.
Perform the following configuration in tunnel interface view.
Table 3-3 Specify source address of the tunnel
Operation
Command
Specify source address of the tunnel.
source { ip-addr | interface-type
interface-num }
Delete the source address of the tunnel.
undo source
3-5
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 3 GRE Configuration
Note:
z
The same source address and destination address cannot be configured on two or
more tunnel interfaces encapsulated with the same protocol.
z
The source command configures actual physical interface address or actual
physical interface. The network address of tunnel interface also needs configuring
by using the ip address command in tunnel interface view.
3.2.4 Specifying Tunnel Destination
After the creation of a tunnel interface, the destination address of the tunnel, that is, IP
address of the actual physical interface receiving GRE packets, also needs to be
specified. A tunnel is uniquely identified by one source address and one destination
address. These configurations are required on both ends of the tunnel, with the source
address at one end being the destination address at the other end and vice versa.
Perform the following configuration in tunnel interface view.
Table 3-4 Specify destination address of the tunnel
Operation
Command
Set destination address of the tunnel.
destination ip-addr
Delete the destination address of the tunnel.
undo destination
Note:
The destination command sets IP address of actual physical interface. In order to
support dynamic routing protocols, network address of tunnel interface also needs
configuring.
3.2.5 Assigning Network Address to Tunnel Interface
You must assign addresses to the interfaces at the ends of a tunnel. The assigned
addresses can be private ones but they must belong to the same network segment.
Perform the following configuration in Tunnel interface view.
Table 3-5 Assign network address to a tunnel interface
Operation
Command
Assign an IP address to the tunnel
interface.
3-6
ip address { ip-addr mask |
unnumbered interface interface-type
interface-number }
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 3 GRE Configuration
Operation
Command
Delete the IP address of the tunnel
interface.
undo ip address
By default, network address of tunnel interface is not configured.
3.2.6 Configuring End-to-End Verification on Both Ends of Tunnel
As RFC1701 provisioned, if the Checksum Present bit in GRE header is set to 1, then
the checksum field is present and contains valid information. The sender calculates the
checksum according to GRE header and payload information and sends the packet
containing the checksum information to the peer end. The receiver calculates the
checksum of the received packet and compares it with the one in the packet. If they are
consistent, the packet that may be discarded otherwise will be further processed.
Checksum can be enabled or disabled on the two ends of a tunnel as needed. If
checksum is enabled only at the local end, the local end will calculate the checksum of
each transmitted packet but will ignore the checksum of received packets; on the
contrary, if checksum is enabled only at the remote end, the local end will verify the
checksum of each received packet but will ignore the checksum of transmitted packets.
Perform the following configuration in tunnel interface view.
Table 3-6 Enable/disable end-to-end verification on both ends of a tunnel
Operation
Command
Enable end-to-end verification on both ends of the tunnel.
gre checksum
Disable end-to-end verification on both ends of the tunnel.
undo gre
checksum
By default, end-to-end verification is disabled on both ends of tunnel.
3.2.7 Setting Identification Key of Tunnel Interface
RFC1701 provisions that if the Key Present bit in the GRE header of a packet is set to 1,
the tunnel identification key carried by the packet will be verified between the sender
and the receiver. The verification will fail if different identification keys are used, and the
packet will be discarded.
Perform the following configuration in tunnel interface view.
3-7
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 3 GRE Configuration
Table 3-7 Set identification key of the tunnel interface
Operation
Command
Set identification key of the tunnel interface.
gre key key-number
Cancel the identification key of tunnel interface.
undo gre key
The key-number parameter is an integer in the range 0 to 4294967295.
By default, tunnel does not use KEY.
3.2.8 Configuring Routing via Tunnel
Tunnel route, either static or dynamic, must exist on both the source and destination
ends, so that GRE packets can be forwarded properly.
I. Configuring static routing
You may manually configure a route to the destination address, which is the destination
address of the packet without GRE encapsulation rather than the destination address
of the tunnel, with the next hop being the address of the remote tunnel interface
address. This configuration is required at both ends of the tunnel. For details about this
configuration, refer to the Routing Protocol module of this manual. For detailed
descriptions on the configuration commands, refer to the Command Manual
accompanying this manual.
II. Configuring dynamic routing
If dynamic routing protocol is running on the firewall, you may simply enable this
protocol on both the tunnel interface and the interface of the firewall directly connected
to the private network. This configuration is required on both ends of the tunnel. For
details about this configuration, refer to the Routing Protocol module of this manual. For
detailed descriptions on the configuration commands, refer to the Command Manual
accompanying this manual.
3.2.9 Configuring the Keepalive Function
Perform the following configuration in tunnel interface view.
Table 3-8 Configure the keepalive function
Operation
Command
Enable the keepalive function of GRE.
keepalive [ seconds [times] ]
Disable the keepalive function of GRE.
undo keepalive
3-8
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 3 GRE Configuration
By default, the keepalive function of GRE is disabled; seconds is set to 10 and times to
3.
After you configure the keepalive command, the firewall sends GRE Keepalive packets
regularly through tunnel interface. If no response is received upon the expiration of a
specified period, the firewall resends the packet. If no response is received yet after the
number of resending attempts exceeds the specified limit, the protocol of the local
tunnel interface goes down.
3.3 Displaying and Debugging GRE
Upon the completion of the above configurations, execute the display command in any
view to view their running state and to verify the effect of the configurations. The
debugging command can be used in user view.
Table 3-9 Display and debug GRE
Operation
Command
Display operating state of tunnel interfaces.
display interface tunnel number
Enable tunnel information debugging.
debugging tunnel
3.4 Typical Configuration Examples of GRE
I. Network requirements
Two subnets Group 1 and Group 2 run IP protocol and are connected through the
firewalls SecPath 1 and SecPath 2, which runs GRE protocol.
II. Network diagram
Ethernet0/0/0
10.1.1.1/24
Ethernet0/0/0
10.1.3.1/24
IP
Group1
Internet
SecPath1
Tunnel1
Ethernet1/0/0
192.13.2.1/24
SecPath 2
Tunnel2
Ethernet2/0/1
131.108.5.2/24
Figure 3-8 Network diagram of GRE application
III. Configuration procedure
1)
Configure firewall SecPath1.
# Configure interface Ethernet 0/0/0.
[H3C] interface ethernet 0/0/0
3-9
IP
Group2
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 3 GRE Configuration
[H3C-Ethernet0/0/0] ip address 10.1.1.1 255.255.255.0
[H3C-Ethernet0/0/0] quit
# Configure interface Serial 0/0/0 (physical interface of tunnel).
[H3C] interface ethernet 1/0/0
[H3C-Ethernet1/0/0] ip address 192.13.2.1 255.255.255.0
[H3C-Ethernet1/0/0] quit
# Create interface Tunnel 1.
[H3C] interface tunnel 1
# Configure IP address of interface Tunnel 1.
[H3C-Tunnel1] ip address 10.1.2.1 255.255.255.0
# Configure encapsulation mode for the tunnel.
[H3C-Tunnel1] tunnel-protocol gre
# Configure source address of interface Tunnel1 (IP address of Ethernet1/0/0).
[H3C-Tunnel1] source 192.13.2.1
# Configure destination address of interface Tunnel1 (IP address of Ethernet2/0/1 on
SecPath2).
[H3C-Tunnel1] destination 131.108.5.2
[H3C-Tunnel1] quit
# Configure static route from SecPath1 to Group2 on interface Tunnel1.
[H3C] ip route-static 10.1.3.0 255.255.255.0 tunnel 1
2)
Configure firewall SecPath2.
# Configure interface Ethernet 0/0/0.
[H3C] interface ethernet 0/0/0
[H3C-Ethernet0/0/0] ip address 10.1.3.1 255.255.255.0
[H3C-Ethernet0/0/0] quit
# Configure interface Ethernet 2/0/1 (physical interface of Tunnel).
[H3C] interface ethernet 2/0/1
[H3C-Ethernet2/0/1] ip address 131.108.5.2 255.255.255.0
[H3C-Ethernet2/0/1] quit
# Create interface Tunnel 2.
[H3C] interface tunnel 2
# Configure IP address for interface Tunnel2
[H3C-Tunnel2] ip address 10.1.2.2 255.255.255.0
# Configure encapsulation mode of the tunnel.
[H3C-Tunnel2] tunnel-protocol gre
# Configure source address of interface Tunnel 2 (IP address of Ethernet 2/0/1).
3-10
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 3 GRE Configuration
[H3C-Tunnel2] source 131.108.5.2
# Configure destination address of interface Tunnel 2 (IP address of Ethernet 1/0/0 on
SecPath1).
[H3C-Tunnel2] destination 192.13.2.1
[H3C-Tunnel2] quit
# Configure static route from SecPath2 to Group 1 via interface Tunnel2.
[H3C] ip route-static 10.1.1.0 255.255.255.0 tunnel 2
3.5 GRE Troubleshooting
GRE configuration is relatively simple, except that you should pay more attention to the
consistency. Most errors can be located by executing the debugging tunnel command.
Here, only one type of error is analyzed, as shown in the following figure:
SecPath1
PC A
10.1.1.1/ 16
Ethernet1/0/0
Tunnel0
SecPath 3
Tunnel
SecPath 2
Ethernet2/0/ 1
Tunnel0
PC B
10.2.1.1/16
Figure 3-9 Troubleshooting example of GRE
Symptom 1: The interfaces at both ends of the tunnel are correctly configured and both
ends of the tunnel can “ping” each other successfully, but PC A and PC B fail to do so.
Troubleshooting: Perform the following steps:
z
In user view, perform the display ip route command on SecPath1 and SecPath2
respectively, making sure there is the route from interface Tunnel1/0/0 to
10.2.0.0/16 on SecPath1, and the route from interface Tunnel 2/0/0 to 10.1.0.0/16
on SecPath2.
z
If the needed static route do not exist in the output information of the above step,
perform the ip route command in system view to add it. Taking SecPath1 for
example, make the following configuration:
[H3C] ip route-static 10.2.0.0 255.255.0.0 tunnel 1/0/0
3-11
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Chapter 4 IPsec Configuration
4.1 IPsec Overview
4.1.1 IPsec
IP security (IPsec) protocol family is a series of protocols defined based on IETF. It
provides high quality, interoperable and cryptology-based security for IP data packets.
The two sides of communication perform encryption and data source authentication on
IP layer to assure confidentiality, data integrity, data origin authentication and
anti-replay for packets when they are being transmitted on networks.
Note:
Confidentiality is to encrypt a client data and then transmit it in cipher text.
Data integrity is to authenticate the received data so as to determine whether the
packet has been modified.
Data origin authentication is to authenticate the data source to make sure that the data
is sent from a real sender.
Anti-replay is to prevent some malicious client from repeatedly sending a data packet.
In other words, the receiver will deny old or repeated data packets.
IPsec implements the above aims via Authentication Header (AH) security protocol and
Encapsulating Security Payload (ESP) security protocol. Moreover, Internet Key
Exchange (IKE) provides auto-negotiation key exchange and Security Association (SA)
setup and maintenance services for IPsec so as to simplify the use and management of
IPsec.
z
AH mainly provides data source authentication, data integrity authentication and
anti-replay. However, it cannot encrypt the packet.
z
ESP provides encryption function besides the above functions that AH provides.
However, its data integrity authentication does not include IP header.
Note:
AH and ESP can be used either independently or corporately. There are two types of
working modes for AH and ESP: transport mode and tunnel mode, which will be
introduced later.
4-1
Operation Manual – VPN
H3C SecPath Series Security Products
z
Chapter 4 IPsec Configuration
IKE is to negotiate the cryptographic algorithm applied in AH and ESP and to
automatically establish SAs and perform key exchange.
Note:
IPsec policy and algorithm can also be negotiated manually. So IKE negotiation is not
necessary. The comparison of these two negotiation modes will be introduced later.
4.1.2 Overview of Encryption Card
IPsec may use ESP or AH protocol to process packets. For high security purpose,
complicated encryption/decryption and authentication algorithms are often used. The
IPsec on a firewall uses many CPU resources for encryption/decryption algorithm, so
the overall performance may be degraded. To solve this problem, you can insert an
encryption card for a modularized firewall, on which IPsec operations are processed by
hardware. This can improve IPsec processing efficiency, as well as overall
performance of a firewall.
1)
Encryption/decryption process on the encryption card: The firewall sends data to
be
encrypted
or
decrypted
to
the
encryption
card.
The
card
runs
encryption/decryption operations and add/delete encryption headers to/from data,
and then sends the processed data back to the firewall for forwarding.
2)
For the IPsec SA implemented by the encryption card, if the card is faulty, backup
function is enabled on the card and the selected encryption/authentication
algorithms for the SA are supported by the IPsec module on Comware platform,
IPsec shall be implemented by the IPsec module on Comware platform. But you
cannot use one encryption card as the backup to another card.
Note:
The encryption card processes data in the same mechanism as the IPsec module on
the Comware platform. The only difference is that the card uses hardware, while the
IPsec module uses software.
4.1.3 IPsec Basic Concepts
I. Security association
IPsec provides security communication between two ends, which are called as IPsec
peers.
4-2
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
IPsec allows systems, network subscribers or administrators to control granularity of
security services between peers. For instance, IPsec policies of some group prescribe
that data flow from some subnet should be protected over AH and ESP and be
encrypted over Triple Data Encryption Standard (3DES) simultaneously. Moreover, the
policies prescribe that data flow from another site should be protected over ESP only
and be encrypted via DES only. IPsec can provide security protection in various levels
for different data flows based on SA.
SA is essential to IPsec. It is the standard for some elements of communication peers.
For example, it determines which protocol should be applied (AH, ESP or both) as well
as the working mode (transport mode or tunnel mode), encryption algorithm (DES and
3DES), shared protecting key in some stream and SA duration.
As SAs are unidirectional, at least two SAs are needed to protect data flow from two
directions in a bi-directional communication. Moreover, if both AH and ESP are applied
to protect data flow between peers, still two SAs are needed for AH and ESP
respectively.
SA is identified by a triplet uniquely, including Security Parameter Index (SPI),
destination IP address and security protocol ID (AH or ESP). SPI is a 32-bit number
generated for uniquely identifying SA. It is transmitted in AH/ESP header.
SA has duration. It is calculated as follows:
z
Time-based duration is to update SA at a specific interval;
z
Traffic-based duration is to update SA after certain data (bytes) transmission.
II. Working mode of IPsec protocol
IPsec protocol falls into two working modes: transport mode and tunnel mode. They are
specified in SA.
In the transport mode, AH/ESP is inserted after the IP header but before all
transmission layer protocols or all other IPsec protocols. In the tunnel mode, AH/ESP is
inserted before the original IP header but after the new header. The data encapsulation
format for various protocols (taking the transmission protocol TCP as an example) in
the transmission/tunnel mode is shown in the following figure:
Mode
Protocol
transport
AH
IP
Header AH
ESP
IP
TCP data ESP ESP
Header ESP Header
Tail Auth data
AH-ESP
TCP
Header
tunnel
new IP
Header AH
data
raw IP
Header
TCP data
Header
raw IP TCP
ESP
new IP
data ESP
Header ESP Header Header
Tail Auth data
raw P
I TCP
IP
TCP data ESP ESP
ESP
new IP
AH ESP
data ESP
Header
Tail Auth data Header AH ESP Header Header
Header
Tail Auth data
Figure 4-1 Data encapsulation format for security protocols
4-3
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
The tunnel mode is safer than the transport mode. It can authenticate and encrypt
original IP data packets completely. Moreover, it can hide the client IP address via the
IPsec peer IP address. On the other hand, the tunnel mode occupies more bandwidth
than the transport mode because it has an extra IP header. Therefore, you can select a
proper mode according to the practical need on security or performance.
III. Authentication algorithm and encryption algorithm
1)
Authentication algorithm
Both AH and ESP can authenticate integrity for an IP packet so as to determine
whether the packet is modified. The authentication algorithm is implemented via hybrid
function. The hybrid function is a kind of algorithm that does not limit the length of
inputting messages and outputs messages in a certain length. The output message is
called as message summary. IPsec peers calculate the packet via the hybrid function
respectively. If they get identical summaries, the packet is integrated and not modified.
Generally speaking, there are two types of IPsec authentication algorithms.
z
MD5: Input a message in any length and generate a 128-bit message summary.
z
SHA-1: Input a message less than 264-bit and generate a 160-bit message
summary.
Because the SHA-1 summary is longer than that of MD5, SHA-1 is safer than MD5.
2)
Encryption algorithm
ESP can encrypt IP packets so that the contents of the packets will not let out during the
transmission. Encryption algorithm is implemented by encrypting or decrypting data
with identical key via symmetric key system. Comware implements three types of
encryption algorithm.
z
DES(Data Encryption Standard): Encrypt a 64-bit simple text via a 56-bit key.
z
3DES (Triple DES): Encrypt a simple text via three 56-bit keys (168 bits key).
z
AES (Advanced Encryption Standard): 128-bit 192-bit and 256-bit AES algorithm,
conforming to IETF standards, can be implemented on Comware.
IV. Negotiation mode
There are two negotiation modes to establish SA: manual mode (manual) and IKE
auto-negotiation mode (isakmp). The former is a bit complex because all information
about SA has to be configured manually. Moreover, it does not support some advanced
features of IPsec, such as key update timer. However, its advantage is that it can
implement IPsec independent of IKE. The latter one is much easier because SA can be
established and maintained by IKE auto-negotiation as long as security policies of IKE
negotiation are configured.
Manual mode is feasible in the case of few peer devices or in a small-sized static
environment. For middle/big-sized dynamic environment, IKE auto-negotiation mode is
recommended.
4-4
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
V. IPsec DPD
IPsec dead peer detection (IPsec DPD) is a function that allows on-demand IKE peer
liveliness detection on IPsec/IKE tunnels.
The idea of DPD is that when an IKE peer receives no packets from its peer for a
specified period, a DPD query is triggered. The IKE peer sends a query to its peer
detecting the liveliness asking for proof of liveliness.
Compared with other keepalive mechanisms available with IPsec, DPD generates less
traffic, but allows more prompt detection and quicker tunnel recovery.
In the scheme using internet security association and key management protocol
security association (ISAKMP SA) established between a router address and a virtual
address of a virtual router redundancy protocol (VRRP) backup group, DPD can
recover rapidly and automatically security tunnels when the master and slave
switchover in a virtual router redundancy protocol (VRRP) backup group. DPD avoids
security tunnels from interrupting when the master and slave switchover, expands the
IPsec application scope, and makes the IPsec protocol more robust.
DPD is implemented in compliance with RFC3706 and RFC2408.
1)
Timers
IPsec DPD uses the following two timers to control sending and receipt of DPD
packets:
z
Interval-time: specifies the idle interval for triggering a DPD query. If an IKE peer
receives no IPsec packet from its peer when this timer times out, DPD query is
triggered.
z
Time-out: specifies the time waiting for a DPD acknowledgement.
2)
Operating mechanism
The following describes how DPD operates after being enabled:
z
At the sender side
An IKE peer does not receive IPsec packets from its peer when interval-time timer
expires and now, it wants to send IPsec packets to its peer. Before that, the IKE peer
sends a DPD query to its peer for proof of liveliness. At the same time, a time-out timer
is started. If no acknowledgement is received upon expiration of this timer, DPD records
one failure event. When the number of failure events reaches three, the involved
ISAKMP SAs and IPsec SAs are deleted.
The same applies to the IPsec SAs set up between a router and the virtual address of a
VRRP standby group: when the failure count reaches three, the security tunnel
between them is deleted. The setup of this security tunnel is triggered only when a
packet matching the IPsec policy is present.
The failover duration depends on the setting of time-out timer. A shorter timer setting
means a shorter communication interruption period but increased overheads.
You are recommended to use the default setting in normal cases.
4-5
Operation Manual – VPN
H3C SecPath Series Security Products
z
Chapter 4 IPsec Configuration
At the responder end
The peer of the sender sends an acknowledgement after receiving the query.
Caution:
If the IKE SA corresponding to IPsec SA has been updated, when a DPD query is
triggered, the DPD query will not take effect, and the IPsec SA will be deleted. DPD
functions again only after a new IKE negotiation is triggered and a new IPsec SA
corresponding to the updated IKE SA is established.
4.1.4 Introduction to IPsec Multi-Instance
IPsec multi-instance function means the MPLS PE and CE can be bound. That is,
IPsec tunnels are set up between the PE and CE. The different interfaces of the PE are
connected to different CEs. Therefore the CEs belonging to different VPNs can set up
IPsec tunnels with the PE respectively, consequently making networking more flexible.
IPSec Tunnel1
VPN ID=1
VPN1-CE1
PE
VPN ID=2
IPSec Tunnel2
VPN2-CE2
Figure 4-2 Network diagram for IPsec multi-instance application
Packets are processed as follows:
z
When forwarding an IP packet to the CE, the PE determines the VPN the packet
belongs to, searches the corresponding VPN routing table, and forwards the
packet to the corresponding outgoing interface according to the VPN ID in the
packet. If you configure IPsec policy on the outgoing interface, the PE encrypts the
packet matching the ACL and sends the packet to the CE.
When receiving the IPsec packet, the PE decrypts the packet first (the PE does not
decrypt non-IPsec packets), then determines the VPN which the packet belongs to
according to the VPN ID of the packet, and searches the corresponding VPN routing
table to determine whether the IP address of the PE is the destination IP address of the
packet. If the destination is the PE, the packet is delivered to the IP layer for processing
4-6
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
(or is forwarded to another CE belonging to the same VPN). If the destination is not the
PE, the packet is encapsulated in a tag according to the VPN routing table
specification.
4.1.5 IPsec on Comware
Comware implements the said aspects of IPsec.
Via IPsec, peers (here refer to the firewall where Comware locates as well as its peer)
can perform various security protections (authentication, encryption or both) on
different data flows, which are differentiated based on ACL. Security protection
elements, such as security protocol, authentication algorithm, encryption algorithm and
operation mode, are defined in IPsec proposal. The association between data flows
and IPsec proposal (namely, apply a certain protection on a certain data flow) together
with SA negotiation mode, peer IP address configuration (i.e., the start/end of
protection path), the required key as well as the duration of SA are defined in IPsec
policies. Finally, IPsec policies are applied on interfaces of the firewall. This is the
process of IPsec configuration.
Following is the detailed description:
1)
Defining data flows to be protected
A data flow is an aggregation of a series of traffics, regulated by source address/mask,
destination address/mask, number of protocol over IP, source port number and
destination port number. An ACL rule defines a data flow, that is, traffic that matches an
ACL rule is a data flow logically. A data flow can be a single TCP connection between
two hosts or all traffics between two subnets. IPsec can apply different security
protections on different data flows. So the first step of IPsec configuration is to define
data flows.
2)
Defining IPsec proposal
IPsec proposal prescribes security protocol, authentication algorithm and encryption
algorithm as well as operation mode (namely, the packet encapsulation mode) for data
flows to be protected.
AH and ESP supported by Comware can be used either independently or corporately.
AH supports MD5 and SHA-1 authentication algorithms. ESP supports MD5 and
SHA-1 authentication algorithms as well as DES, 3DES and AES encryption algorithms.
Working mode supported by Comware includes transport mode and tunnel mode.
As for a data flow, peers should be configured with identical protocol, algorithm and
working mode. Moreover, if IPsec is applied on two firewalls (such as between
Comware firewalls), the tunnel mode is recommended so as to hide the real source and
destination addresses.
Therefore, you should define an IPsec proposal based on requirements so that you can
associate it with data flows.
4-7
Operation Manual – VPN
H3C SecPath Series Security Products
3)
Chapter 4 IPsec Configuration
Defining IPsec policy or IPsec policy group
IPsec policy specifies a certain IPsec proposal for a certain data flow. An IPsec policy is
defined by “name” and “sequence number” uniquely. It falls into two types, manual
IPsec policy and IKE negotiation IPsec policy. The former one is to configure
parameters such as key, SPI as well as IP addresses of two ends in the tunnel mode
manually. As for the latter one, these parameters are automatically generated by IKE
negotiation.
An IPsec policy group is an aggregation of IPsec policies with identical name but
different sequence numbers. In an IPsec policy group, the smaller the sequence
number is, the higher the priority is.
4)
Applying IPsec policies on an interface
Apply all IPsec policies in a group on an interface so as to perform different security
protections on different data flows passing the interface.
4.2 IPsec Configuration
I. Configuring IPsec
1)
Configure ACL
2)
Configure a security proposal
z
Create a security proposal (IPsec proposal or card SA proposal)
z
Specify the encryption card used in the card SA proposal (only applies to
encryption cards)
z
Select security protocol
z
Select security algorithm
z
Select packet encapsulation mode
3)
Create security policy (manually or by using IKE)
For manual mode:
z
Create security policy
z
Import ACL into security policy
z
Configure starting and end points for tunnel
z
Configure SPI for SA
z
Configure SA keys
For IKE mode:
z
Create security policy using IKE
z
Import card SA proposal into security policy
z
Import ACL into security policy
z
Import IKE peer into security policy
z
Configure SA duration (optional)
z
Configure PFS feature for negotiation (optional)
A security policy can reference an IPsec proposal or card SA proposal as needed.
4-8
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
4)
Configure security policy template (optional)
5)
Apply security policy on the interface
6)
Disable next-payload field checking (optional)
II. Configuring the encryption card (optional)
1)
Enable the encryption card
2)
Enable Comware main software backup
3)
Configure the fast forwarding function of the encryption card
4)
Configure the simple network management operations for the encryption card
4.2.1 Defining ACL
IPsec uses the advanced ACL to determine which packets need to be protected. The
role of the advanced ACL in IPsec is different from what introduced in firewalls.
Normally, advanced ACL is used for determining which data can be permitted and
which must be denied on which interface. Advanced ACL in IPsec, however, is used by
IPsec to determine which packet needs security protection and which does not. For this
reason, advanced ACL applied in IPsec is in fact encryption ACL. Packets permitted by
Encryption ACL will be in protection, while packets denied by the ACL will not be
protected. An encryption ACL can apply on both input interfaces and output interfaces.
For more information about ACL configuration, see the Security part of this manual.
The negotiation succeeds only after you configure the mirror of the sender’s ACL to be
the subset of the receiver’s ACL, or ACLs of both ends to be the mirror of each other.
You are recommended to adopt the second configuration. Refer to the following
example.
Local end:
acl number 3101
rule 1 permit ip source 173.1.1.0 0.0.0.255 destination 173.2.2.0 0.0.0.255
Peer end:
acl number 3101
rule 1 permit ip source 173.2.2.0 0.0.0.255 destination 173.1.1.0 0.0.0.255
Note:
IPsec protects the data flow permitted in the ACL, therefore, the users are
recommended to configure the ACL accurately, that is, to configure permit only to the
data flow that needs IPsec protection so as to avoid the excessive use of the keyword
any.
4-9
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Executing the display acl all command will display all the ACLs, including all the
advanced IP ACLs regardless whether they are for communications filtering or for
encryption. Simply speaking, the system does not discriminate the advanced ACLs for
these two purposes in the output information of this command.
4.2.2 Defining an IPsec Proposal
An
IPsec
proposal
saves
the
particular
security
protocol
and
the
encryption/authentication algorithms applied in IPsec, intending for providing security
parameters for IPsec to make SA negotiation. To ensure the success of a negotiation,
the two ends involved in the negotiation must use the same IPsec proposal.
Perform the following tasks to configure a security proposal.
z
Create an IPsec or card SA proposal
z
Specify the encryption card in the card SA proposal (only applied when an
encryption card is involved)
z
Select packet encapsulation mode
z
Select a security protocol
z
Select a security algorithms
I. Creating an IPsec or card SA proposal
An IPsec proposal is a set of security protocol, algorithms and packet encapsulation
format used to implement IPsec protection. An IPsec policy can determine the adopted
security protocol, algorithms, and encapsulation mode by referencing one or more
IPsec proposals. Before an IPsec proposal is referenced by IPsec policy, this IPsec
proposal must be established.
You are allowed to modify an IPsec proposal, but such modifications cannot take effect
at all if the modified proposal is applied to an SA that has been setup between the two
sides after negotiation – unless you execute the reset ipsec sa (or reset encrypt-card
sa) command to reset the SA. New security proposals can only apply to new SAs.
Perform the following configuration in system view.
Table 4-1 Configure an IPsec proposal
Operation
Command
Create an IPsec proposal and access
the IPsec proposal view (for IPsec
module)
ipsec proposal proposal-name
Delete the IPsec proposal (for IPsec
module)
undo ipsec proposal proposal-name
Create a card SA proposal and access
its view (for encryption cards only )
ipsec card-proposal proposal-name
4-10
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Operation
Command
Delete the card SA proposal (for
encryption card)
undo ipsec card-proposal
proposal-name
By default, no security proposal is configured.
II. Specifying the encryption card to be used by a security proposal (only
applied when an encryption card is involved)
When an encryption card is used, you must specify its slot number in card SA proposal
view; each card can be assigned to multiple encryption card security proposals. In
system view, use the ipsec card-proposal proposal-name command to enter
encryption card SA proposal view, and then specify the encryption card to be used by a
security proposal in this view.
Table 4-2 Assign an encryption card to the card SA proposal
Operation
Command
Enter the encryption card SA proposal view
ipsec card-proposal proposal-name
Assign an encryption card to the card SA
proposal
use encrypt-card slot-id
Remove the configuration
undo use encrypt-card
By default, no encryption card is used in the card SA proposal.
III. Selecting packet encapsulation mode
You MUST specify encapsulation mode in a security proposal. In addition, the same
encapsulation mode MUST be adopted at the two ends of a security tunnel.
Perform the following configuration in IPsec proposal or card SA proposal view.
Table 4-3 Select a packet encapsulation mode
Operation
Command
Set the IP datagram encapsulation
mode adopted by the security protocol.
encapsulation-mode { transport |
tunnel }
Restore the default encapsulation mode.
undo encapsulation-mode
Normally, tunnel mode is always adopted between two security GWs (routers).
Transport mode is always preferred, however, with respect to the communication
between two hosts or between a host and a security GW.
By default, tunnel mode is adopted.
4-11
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
IV. Selecting security protocol
The security protocol needs specifying in the IPsec proposal and by far AH and ESP
are the only two options. You are allowed to use AH, ESP, or both, but the choice must
be the same as that at the remote end of the security tunnel.
Perform the following configuration in IPsec proposal or card SA proposal view.
Table 4-4 Select security protocol
Operation
Command
Configure security protocol used by
IPsec proposal
transform { ah | ah-esp | esp }
Restore default security protocol
undo transform
By default, esp (defined by RFC 2406) applies.
V. Selecting security algorithm
Different security protocols may use different authentication and encryption algorithms.
Currently AH supports the MD5 and SHA-1 authentication algorithms, while ESP
supports the MD5 and SHA-1 authentication algorithms and the DES, 3DES and AES
encryption algorithms.
Perform the following configuration in IPsec proposal or card SA proposal view.
Table 4-5 Select security algorithm
Operation
Command
Configure encryption algorithm used by
ESP
esp encryption-algorithm { 3des | des
| aes }
Configure undo packet encrypting for
ESP
undo esp encryption-algorithm
Configure authentication method used
by ESP
esp authentication-algorithm { md5 |
sha1 }
Configure undo packet authentication
for ESP
undo esp authentication-algorithm
Configure authentication method used
by AH protocol
ah authentication-algorithm { md5 |
sha1 }
Restore AH protocol default
authentication method
undo ah authentication-algorithm
ESP will allow encryption and authentication process for packet at the same time, or
encryption
only
or
process
authentication
only.
Attention,
undo
esp
authentication-algorithm command will not restore authentication method to the
default, but configure authentication method as null, i.e., undo authentication-method.
4-12
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
When encryption algorithm is null, undo esp authentication-algorithm command is
invalid. AH protocol has no encrypting function and can only perform authentication for
packets. undo ah authentication-algorithm command is used to restore AH protocol
default authentication method as md5. On both ends of security tunnel, the IPsec
proposals referenced by IPsec policy must be configured with the same authentication
method and encryption algorithm.
ESP protocol supports three types of encryption algorithms: des, 3des and aes, and
two authentication algorithms: hmac-md5 and hmac-sha1.
AH protocol supports two types of authentication algorithms: hmac-md5 and
hmac-sha1.
By default, encryption algorithm used by ESP is des and authentication method used is
md5. Authentication method used by AH protocol is md5.
Note:
Only when the desired security protocol is selected with the transform command, can
security algorithm be configured. For example, if you can select ESP, you can only
configure those security algorithms particular to ESP, excluding those for AH.
4.2.3 Creating an IPsec Policy
IPsec policy specifies a certain IPsec proposal for a certain data flow. An IPsec policy is
defined by “name” and “sequence number” uniquely. It falls into two types, manual
IPsec policy and IKE negotiation IPsec policy. The former one is to configure
parameters such as key, SPI and SA duration as well as IP addresses of two ends in
the tunnel mode manually. As for the latter one, these parameters are automatically
generated by IKE negotiation.
Note:
This section introduces configurations about IPsec policy in detail, including manual
configuration and IKE negotiation configuration. Configuration for one mode will be
followed by a special description. Otherwise, the configuration should be performed in
both manual mode and IKE negotiation mode.
I. Manually creating an IPsec policy
1)
Manually creating an IPsec policy
4-13
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
You are not allowed to modify the negotiation mode of an IPsec policy that has been
created. For example: If manual IPsec policy is established, it cannot be revised into
isakmp mode, and you have to delete this IPsec policy before establishing a new one.
Perform the following configuration in system view.
Table 4-6 Establish IPsec policy
Operation
Command
Manually create an IPsec policy for an
SA.
ipsec policy policy-name seq-number
manual
Modify the IPsec policy of the SA.
ipsec policy policy-name seq-number
manual
Delete the IPsec policy
undo ipsec policy policy-name
[ seq-number ]
IPsec policies with the same name and different sequence numbers can compose an
IPsec policy group. In one IPsec policy group, up to 500 IPsec policies can be
configured. However, the maximum number of all IPsec policies in all IPsec policy
groups is 500. In an IPsec policy group, the smaller the sequence number is, the higher
the priority will be.
By default, there is no IPsec policy.
2)
Referencing IPsec proposal in IPsec policy
IPsec policy will specify security protocol algorithm and packet encapsulation format by
referencing IPsec proposal. Before an IPsec proposal is referenced, this IPsec
proposal must be configured.
Perform the following configuration in system view.
Table 4-7 Use IPsec proposal in IPsec policy
Operation
Command
Configure IPsec proposal referenced by
IPsec policy
proposal proposal-name1
[ proposal-name2... proposal-name6 ]
Remove IPsec proposal referenced by
IPsec policy
undo proposal [ proposal-name ]
The Security Association can be established through manual mode. One IPsec policy
can reference only one IPsec proposal. If IPsec proposal has been configured, the
former IPsec proposal must be removed so as to configure new IPsec proposal. On
both ends of security tunnel, IPsec proposals referenced by the IPsec policy must be
configured by using the same security protocol, algorithm and packet encapsulation
mode.
3)
Configuring ACL referenced in IPsec policy
4-14
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
IPsec policy will reference access control list. IPsec will specify which packet needs
security protection and which does not according to the rules in this access control list.
Packets permitted by ACL will be in protection, while packets denied by ACL will not be
protected.
Perform the following configuration in IPsec policy view.
Table 4-8 Configure access control list referenced by IPsec policy
Operation
Command
Configure access control list referenced by IPsec policy
security acl acl-number
Remove access control list referenced by IPsec policy
undo security acl
One IPsec policy can reference only one ACL. If the IPsec policy has referenced more
than one ACL, only the last configured one is valid.
As for a manually established IPsec policy, only one ACL rule can be protected in
standard mode. That is, only the packet that first matches this ACL can be protected,
while the packets that match other rules of this ACL will not be protected.
4)
Configuring tunnel start/end point
Generally, tunnels applying IPsec policies are called “security tunnels”. A security
tunnel is set up between the local and the peer GWs. To ensure the success in security
tunnel setup, you must configure correct local and peer addresses.
Perform the following configuration in IPsec policy view.
Table 4-9 Configure tunnel start/end point
Operation
Command
Configure local address in the IPsec policy
tunnel local ip-address
Delete the local address configured in the
IPsec policy
undo tunnel local
Configure peer address in the IPsec policy.
tunnel remote ip-address
Delete the peer address configured in the
IPsec policy.
undo tunnel remote [ ip-address ]
With respect to an IPsec policy set up manually, only if both local and peer addresses
are correctly configured, can a security tunnel be set up. (As ISAKMP SA can
automatically obtain local and peer addresses, it does not require the configuration of
local or peer address.
5)
Configuring SA SPI
This configuration task only applies to a manually created IPsec policy. Use the
following command to configure SA SPI for manually creating an SA. An isakmp-mode
4-15
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
IPsec policy does not need manual configuration and IKE will automatically negotiate
SPI and create SA.
Perform the following configuration in IPsec policy view.
Table 4-10 Configure an SA SPI
Operation
Command
Configure an SA SPI.
sa spi { inbound | outbound } { ah | esp } spi-number
Delete the SA SPI.
undo sa spi { inbound | outbound } { ah | esp }
When configuring an SA for the system, you must set the parameters in the inbound
and outbound directions separately.
The SA parameters set at both ends of the security tunnel must be fully matched. The
SPI and key in the inbound SA at the local must be the same as those in the outbound
SA at the remote. Likewise, the SA SPI and key in the outbound SA at the local must be
the same as those in the inbound SA at the remote.
6)
Configuring key for SA
This configuration is used only for manual mode IPsec policy. Security association key
can be input manually by using the following commands. (For isakmp negotiation
IPsec policy, manual configuration for key is not required. IKE will automatically
negotiate security association key.)
Perform the following configuration in IPsec policy view.
Table 4-11 Configure key used by security association
Operation
Command
Configure AH protocol authentication
key
(input in hex form)
Configure protocol key
sa authentication-hex { inbound |
outbound } { ah | esp } hex-key
sa string-key { inbound | outbound }
{ ah | esp } string-key
(input in character string)
Configure ESP encryption key
sa encryption-hex { inbound |
outbound } esp hex-key
(input in hex form)
undo sa string-key { inbound |
outbound } { ah | esp }
Delete configured security association
parameter
undo sa authentication-hex { inbound
| outbound } { ah | esp }
undo encryption-hex { inbound |
outbound } esp
4-16
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
On both ends of security tunnel, configured Security Association parameters must be
consistent. Security association SPI and shared secret input on local end must be the
same as peer output Security Association SPI and shared secret. Security association
SPI and shared secret output on local end must the same as those input on peer end.
For the character string key and hex string key, the last configured one will be adopted.
On both ends of security tunnel, shared secret should be input in the same form. If
shared secret is input in character string on one end and in hex on the other end, the
security tunnel cannot be correctly established.
II. Creating an IPsec policy by using IKE
Following are the configuration tasks for creating an IPsec policy by using IKE.
z
Create an IPsec policy by using IKE
z
Reference an IPsec proposal in the IPsec policy
z
Configure ACL referenced by the IPsec policy
z
Referencing an IKE peer in the IPsec policy
z
Configure the lifetime of an SA (optional)
z
Configure the PFS feature in negotiation (optional)
z
Configure IPsec DPD (optional)
1)
Creating an IPsec policy by using IKE
Perform the following configuration in system view.
Table 4-12 Create an IPsec policy
Operation
Command
Create an IPsec policy by using IKE and
access the IPsec policy view.
ipsec policy policy-name seq-number
isakmp
Dynamically create an IPsec policy by
using IKE and an IPsec policy template.
ipsec policy policy-name seq-number
isakmp [ template template-name ]
Modify an IPsec policy that has been
established by using IKE negotiation
ipsec policy policy-name seq-number
isakmp
Delete the specified IPsec policy.
undo ipsec policy policy-name
[ seq-number ]
If you want to create a dynamic IPsec policy by making use of an IPsec policy template,
you must first define the policy template. For more information about defining a policy
template, see section 4.2.4 “Configuring IPsec Policy Template.”
2)
Referencing an IPsec proposal in the IPsec policy
An IPsec proposal is referenced in an IPsec policy to specify IPsec protocol, algorithms,
and packet encapsulation mode. Before an IPsec proposal can be referenced, it must
have been created.
Perform the following configuration in IPsec policy view.
4-17
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Table 4-13 Reference an IPsec proposal in the IPsec policy
Operation
Command
Reference an IPsec proposal in the
IPsec policy.
proposal proposal-name1
[ proposal-name2... proposal-name6 ]
Remove the IPsec proposal referenced
by the IPsec policy.
undo proposal [ proposal-name ]
In the event of setting up an SA by making use of IKE (isakmp) negotiation, each IPsec
policy can reference up to six IPsec proposals. When making an IKE negotiation, the
systems at the two ends of the security tunnel will look up the configured IPsec
proposals for a match. If no match is found, the setup attempt of SA will fail and the
packets requiring protection will be dropped.
3)
Referencing ACL in the IPsec policy
IPsec policy will reference an ACL to specify which packet needs security protection
and which does not according to the rules in this access control list. Packets permitted
by ACL will be in protection, while packets denied by ACL will not be protected.
Perform the following configuration in IPsec policy view.
Table 4-14 Reference ACL in the IPsec policy
Operation
Command
Reference an ACL in the IPsec policy
security acl acl-number
Remove the ACL referenced by the IPsec policy
undo security acl
One IPsec policy can reference only one ACL. If the IPsec policy has referenced more
than one ACL, only the last configured one is valid.
4)
Referencing an IKE peer in the IPsec policy
In IKE negotiation mode, these parameters such as peer, SPI and key can be obtained
through negotiation, so you only need to associate IPsec policy with IKE peer. The IKE
peer must be established before being referenced.
Perform the following configuration in IPsec policy view.
Table 4-15 Reference an ACL in the IPsec policy
Operation
Command
Reference an IKE peer in the IPsec policy.
ike peer peer-name
Remove the referenced IKE peer from the IPsec
policy.
undo ike peer
[ peer-name ]
4-18
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Note:
This section only discusses importing IKE peer for IPsec, but in practice other
parameters also need to be configured in IKE Peer view, including IKE negotiation
mode, ID type, NAT traversal, shared key, peer IP address, peer name etc. Refer to the
next chapter for such details.
5)
Configuring SA duration (lifetime) (optional)
a. Configuring global SA lifetime
All the SAs that have not been configured separately with a lifetime in IPsec policy view
adopt the global lifetime. In the SA negotiation via IKE, the lifetime configured at the
local or at the peer will be adopted, whichever is smaller.
There are two types of lifetime: “time-based" lifetime and “traffic-based” lifetime. The
expiration of either type of lifetime will render an SA useless. Before it goes invalid, IKE
will negotiate to set up a new SA for IPsec. Thus, when the old SA becomes fully invalid,
a new one is available.
Perform the following configuration in system view.
Table 4-16 Configure a global SA lifetime
Operation
Command
Configure a global SA lifetime.
ipsec sa global-duration { traffic-based
kilobytes | time-based seconds }
Restore the default global SA lifetime.
undo ipsec sa global-duration
{ traffic-based | time-based }
Changing the configured global lifetime does not affect the IPsec policies that have
separate lifetimes or the SAs that have been set up. The changed global lifetime will
apply to the IKE negotiation initiated later.
Lifetime is not significant to manually established SAs but isakmp mode SAs. In other
words, a manually established SA will maintain permanently.
b. Configuring SA lifetime in IPsec policy view
You can configure a separate SA lifetime for an IPsec policy. If such a lifetime is not
available, the global SA lifetime will apply.
In the SA negotiation via IKE, the lifetime configured at the local or at the peer will be
adopted, whichever is smaller.
Perform the following configuration in IPsec policy view.
4-19
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Table 4-17 Configure an SA lifetime
Operation
Command
Configure an SA lifetime for the IPsec
policy.
sa duration { traffic-based kilobytes |
time-based seconds }
Adopt the configured global SA lifetime.
undo sa duration { traffic-based |
time-based }
Changing the configured global lifetime does not affect the SAs that have been set up.
The changed global lifetime will apply to the IKE negotiation initiated later.
6)
Configuring the PFS feature in negotiation (optional)
Perfect Forward Secrecy (PFS) is a security feature. With it, keys are not derivative, so
the compromise of a key will not threaten the security of other keys. This feature is
implemented by adding the process of key exchange in the stage-2 negotiation of IKE.
This command is only significant to isakmp mode SAs.
Perform the following configuration in IPsec policy view.
Table 4-18 Set the PFS feature used in negotiation
Operation
Command
Configure the PFS feature used in
negotiation.
pfs { dh-group1 | dh-group2 |
dh-group5 | dh-group14 }
Disable PFS in negotiation.
undo pfs
When IKE initiates a negotiation by using an IPsec policy configured with the PFS
feature, it will make a key exchange operation. In the event that the local adopts PFS,
the peer must also adopt PFS. The local and the peer must specify the same
Diffie-Hellman (DH) group; otherwise, the negotiation between them will fail.
The group2 provides a security level higher than group1 (the group5 provides a
security level higher than group2, and the rest may be deduced by analogy),, but it
needs longer time for calculation.
By default, PFS feature is not configured.
7)
Configuring IPsec DPD (optional)
z
Creating a DPD structure
Perform the following configuration in system view.
4-20
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Table 4-19 Create a DPD structure and enter its view
Operation
Command
Create a DPD structure and enter its view
ike dpd dpd-name
Delete the specified DPD structure
undo ike dpd dpd-name
A DPD data structure, or a DPD structure, contains DPD query parameters, such as
interval-time timer and time-out timer. A DPD structure can be referenced by multiple
IKE peers. Thus, you need not to configure one DPD structure for each interface. If a
DPD structure has been referenced by an IKE peer, it cannot be deleted.
Configuring timers
z
Perform the following configuration in DPD structure view.
Table 4-20 Configure timers
Operation
Command
Configure the interval for triggering a DPD query
interval-time seconds
Restore the default interval for triggering a DPD query
undo interval-time
Configure the time waiting for a DPD acknowledgment
time-out seconds
Restore the default time waiting for a DPD
acknowledgment
undo time-out
By default, the interval for triggering a DPD query is 10 seconds, and the time waiting
for a DPD acknowledgment is five seconds.
Specifying a DPD structure for an IKE peer
z
Perform the following configuration in IKE peer view.
Table 4-21 Specify a DPD structure for an IKE peer
Operation
Command
Specify a DPD structure for the IKE peer
dpd dpd-name
Remove the referenced DPD structure
undo dpd
4.2.4 Configuring IPsec Policy Template
When creating the IPsec policy using IKE, you can configure the IPsec policy in IPsec
policy view directly. Besides, you can create the IPsec policy by using IPsec policy
template. In this case, you need to configure all IPsec policies in IPsec policy template
first.
4-21
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
The configuration of IPsec policy template is similar to common IPsec policy: first, you
need create a policy template, then, template parameters can be specified.
Perform the following configuration in system view.
Table 4-22 Configure IPsec policy template
Operation
Command
Create/Modify IPsec policy template
ipsec policy-template template-name
seq-number
Delete an IPsec policy template
undo ipsec policy-template
template-name [ seq-number ]
Using IPsec policy-template command, you will enter the IPsec policy template view, in
which you can specify the policy template related parameters.
Note:
The parameters configurable in an IPsec policy template are the same as those of
IPsec policy, but most are optional. Only IPsec proposal and IKE peer (you do not need
to configure the remote IP address in IKE peer) are mandatory. However, it should be
noted that the proposal parameters are mandatory while other parameters are optional.
In IKE negotiation, if IPsec policy template is used for policy matching, the configured
parameters must be matched and the parameters not configured use those of the
initiation side.
After the configuration of policy template, the following command must be executed to
apply the policy template just defined.
Table 4-23 Reference IPsec policy template
Operation
Command
Reference an IPsec policy template
ipsec policy policy-name seq-number
isakmp template template-name
When using the IPsec policy template to create the IPsec policy, you cannot configure
or modify the IPsec policy in IPsec policy view, while you can do so in IPsec policy
template view.
4-22
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Caution:
The policy of IPsec policy template cannot initiate the negotiation of security
association, but is can response a negotiation.
4.2.5 Applying IPsec Policy Group to Interface
In order to validate a defined SA, you must apply an IPsec policy group at the interface
(logical or physical) where the outgoing data or incoming data needs encryption or
decryption. Data encryption on the interface will be made based on the IPsec policy
group and in conjunction with the peer firewall. Deleting the IPsec policy group from the
interface will disable the protection function of IPsec on the interface.
Perform the following configuration in interface view.
Table 4-24 Use IPsec policy group
Operation
Command
Use the IPsec policy group
ipsec policy policy-name
Remove the IPsec policy group in use
undo ipsec policy [ policy-name ]
An interface can only use one IPsec policy group. Only ISAKMP IPsec policy group can
be used on more than one interface. A manually configured IPsec policy group can only
be used on one interface.
When packet transmitted from an interface, each IPsec policy in the IPsec policy group
will be searched according to sequence numbers in ascending order. If an access
control list referenced by the IPsec policy permits a packet, the packet will be
processed by this IPsec policy. If the packet is not permitted, keep on searching the
next IPsec policy. If the packet is not permitted by any access control list referenced by
the IPsec policy, it will be directly transmitted (IPsec does not protect the packet).
The IPsec policy implementation of firewall can not only apply on practical physical
ports such as serial ports and Ethernet ports, but also on virtual interfaces such as
Tunnel and Virtual Template. In this way, IPsec can be applied on tunnels like GRE and
L2TP according to the practical network requirements.
To delete all IKE SAs, you need to delete the IPsec policies on all the interfaces, or
manually delete the SAs or wait until the IKE SAs time out.
4.2.6 Disabling Next-Payload Field Checking
An IKE negotiation packet comprises multiple payloads; the next-payload field is in the
generic header of the last payload. According to the protocol, this field should be set to
4-23
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
0. It however may vary by vendor. For compatibility sake, you can use the following
command to ignore this field during IPsec negotiation.
Table 4-25 Disable to check the next-payload field
Operation
Command
Disable to check the next-payload field
in the last payload of the IKE negotiation
packet during IPsec negotiation
ike next-payload check disabled
Remove the default
undo ike next-payload check
disabled
By default, the system checks the next-payload field in the last payload of the IKE
negotiation packet during IPsec negotiation.
4.2.7 Configuring IPsec Fragments Buffering
When an interface is configured with IPsec security policy, any packet received on or
sent from the interface is matched against the ACLs before other IPsec handling.
If the packet happens to be a fragment, the subsequent fragments will be unable to
match the security policy for not containing port number and other information.
z
If the fragments arrive in order (that is, the first fragment arrives earlier than the
non-first fragments), the first fragment will create a fragment table entry, and fill the
content after matching the security policy. The subsequent fragments are then
matched against this entry before other IPsec handling.
z
If the non-first fragments arrive earlier than the first fragments, they have to wait for
the first fragment to establish the fragment entry. The IPsec fragments buffering
provides the mechanism to temporarily store these fragments while they are
waiting.
I. Configuring IPsec fragments buffering mechanism
Perform the following configuration in system view.
Table 4-26 Configure IPsec fragments buffering mechanism
Operation
Command
Enable fragments buffering in the
inbound direction
ipsec fragment-chain inbound enable
Disable fragments buffering in the
inbound direction
ipsec fragment-chain inbound
disable
4-24
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Operation
Command
Enable fragments buffering in the
outbound direction
ipsec fragment-chain outbound
enable
Disable fragments buffering in the
outbound direction
ipsec fragment-chain outbound
disable
By default, fragments buffering is disabled. That is, if non-first fragments arrive earlier
than the first fragment, they will be discarded.
II. Configuring timeout time of buffered fragments
Perform the following configuration in system view.
Table 4-27 Configure timeout time of buffered fragments
Operation
Command
Configure the timeout out of buffered
fragments
ipsec fragment-chain timeout
seconds
By default, the timeout time is 3 seconds.
4.2.8 Configuring the Encryption Card (Optional)
The basic configurations of an encryption card are the same as those of IPsec; refer to
the previous sections.
The following are the optional configurations for the encryption card.
I. Entering encryption card interface view and enabling the card
When a firewall is fitted with multiple encryption cards, you may use the undo
shutdown and shutdown commands to enable or disable them. The undo shutdown
command can reset and initialize an encryption card that is disabled.
Before you can shut down/enable the encryption card in a specified slot, you must use
the interface encrypt command to enter the view of the encryption card.
Perform the following configuration in system view.
Table 4-28 Enter encryption card interface view
Operation
Command
Enter encryption card interface view
interface encrypt slot-id
Perform the following configuration in encryption card interface view.
4-25
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Table 4-29 Enable or shut down the encryption card
Operation
Command
Turn up the encryption card
undo shutdown
Shut down the encryption card
shutdown
By default, all the fitted encryption cards are up.
II. Enabling IPsec module backup function
For the IPsec SA implemented by the encryption card, if the card is normal, IPsec is
processed by the card. If the card fails, backup function is enabled on the card and the
selected encryption/authentication algorithms for the SA are supported by the IPsec
module on Comware platform, IPsec shall be implemented by the IPsec module on
Comware platform. In the event that the selected algorithms are not supported by the
IPsec module, the system drops packets.
Perform the following configuration in system view.
Table 4-30 Configure IPsec module backup function
Operation
Command
Enable IPsec module backup function
encrypt-card backuped
Disable IPsec module backup function
undo encrypt-card backuped
By default, IPsec module backup function is disabled.
III. Configuring the fast forwarding function of the encryption card
For the packets that have the same [SourIP, SourPort, DestIP, DestPort, Prot] quintuple,
the firewall creates a fast forwarding entry when it receives the first packet. Then, the
subsequent packets, rather than processed packet by packet, are sent directly to the
encryption card, where they are sent to the destination after being encrypted or
decrypted. This is how the fast forwarding function of the encryption card expedites
packet processing.
Perform the following configuration in system view.
Table 4-31 Configure the fast forwarding function of the encryption card
Operation
Command
Enable the fast forwarding function of
the encryption card
encrypt-card fast-switch
Disable the fast forwarding function of
the encryption card
undo encrypt-card fast-switch
4-26
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
By default, the fast forwarding function of the encryption card is disabled.
Caution:
After the fast forwarding function of encryption card is enabled, the statistic information
of the packets processed by the encryption card will not be shown in ACL.
IV. Setting simple network management configuration on encryption cards
You can manage the encryption cards on the firewall remotely by using SNMP. With the
NM function on the firewall, you can query the card status and monitor trap information,
which includes information about card rebooting, status transition and packet loss
processing.
Perform the following configuration in system view.
Table 4-32 Configure trap function on Encryption card
Operation
Command
Enable trap function on Encryption card
snmp-agent trap enable encrypt-card
Disable trap function on Encryption card
undo snmp-agent trap enable
encrypt-card
By default, the trap function is enabled on the encryption card.
4.3 Displaying and Debugging IPsec
4.3.1 Displaying and Debugging over IPsec Module on Comware Platform
I. Displaying and debugging IPsec configuration
After the above configuration, execute display command in any view to display the
running of the IPsec configuration, and to verify the effect of the configuration.
Execute debugging command in user view for the debugging of IPsec configuration.
Table 4-33 Display and debug IPsec
Operation
Command
Display Security Association related
information
display ipsec sa [ brief | remote
ip-address | policy policy-name
[ seq-number ] | duration ]
Display IPsec tunnel information
display ipsec tunnel
4-27
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Operation
Command
Display statistical information on IPsec
processed packet
display ipsec statistics
Display IPsec proposal
display ipsec proposal
[ proposal-name ]
Display IPsec policy
display ipsec policy [ brief | name
policy-name [ seq-number ] ]
Display IPsec policy template
display ipsec policy-template [ brief |
name policy-name [ seq-number ] ]
Display IPsec fragments buffering
information
display ipsec fragment buffer-chain
Display statistics of IPsec buffered
fragments
display ipsec fragment statistics
Display DPD configuration information
display ike dpd [ dpd-name ]
Enable IPsec debugging function
debugging ipsec { all | sa | packet
[ policy policy-name [ seq-number ] |
parameters ip-address protocol
spi-number ] | fragment | misc }
Disable IPsec debugging function
undo debugging ipsec { all | sa |
packet [ policy policy-name
[ seq-number ] | parameters ip-address
protocol spi-number ] | fragment |
misc }
Enable DPD debugging function
debugging ike dpd
Disable DPD debugging function
undo debugging ike dpd
II. Clearing IPsec packet statistics
This command clears IPsec packet statistics. All statistical information is set to 0.
Perform the following configuration in user view.
Table 4-34 Clear IPsec packet statistics
Operation
Command
Clear IPsec packet statistics
reset ipsec statistics
III. Clearing the statistics of IPsec buffered fragments
All the statistics are set to zero after this configuration.
Perform the following configuration in user view.
4-28
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Table 4-35 Clear the statistics of IPsec buffered fragments
Operation
Command
Clear the statistics of IPsec buffered
fragments
reset ipsec fragment statistics
IV. Clearing the queues of IPsec buffered fragments
All the fragments in the queues are discarded after this configuration.
Perform the following configuration in user view.
Table 4-36 Clear the queues of IPsec buffered fragments
Operation
Command
Clear the queues of IPsec buffered
fragments
reset ipsec fragment buffer-chain
V. Deleting SA
The configuration is used to delete the established SA (either manually or through IKE
negotiation). If no parameter is specified, all the SAs will be deleted.
Perform the following configuration in user view.
Table 4-37 Delete SA
Operation
Delete SA
Command
reset ipsec sa [ remote ip-address | policy policy-name
[ seq-number ] | parameters ip-address protocol spi-number ]
If a packet re-triggers IKE negotiation after an SA set up through IKE negotiation is
deleted, IKE will reestablish an SA through negotiation.
If an SA set up manually is deleted, the system will automatically set up a new SA
according to the parameter manually set up.
The keyword parameters will take effect only after the spi of the outbound SA is
defined. Because SAs appear in pairs, the inbound SA will also be deleted after the
outbound SA is deleted.
4.3.2 Displaying and Debugging Encryption Card Information
I. Displaying and debugging IPsec information on encryption cards
You can view the IPsec configurations, including SA information, statistics, log,
interface information and IPsec module backup function, on the encryption card using
display commands.
4-29
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Execute the debugging command in user view for the debugging of IPsec
configuration.
Table 4-38 Display and debug encryption card configuration
Operation
Command
Display interface information on the
encryption card
display interface encrypt slot-id
Display information about the fast
forwarding cache for the encryption
cards
display encrypt-card fast-switch
Enable Comware test software
debugging on the encryption card
debugging encrypt-card host { all |
packet | sa | command | error | misc }
Disable Comware test software
debugging on the encryption card
undo debugging encrypt-card host
{ all | packet | sa | command | error |
misc }
II. Clearing statistics on encryption card
Use this command to clear statistics of the encryption cards.
Perform the following configuration in user view.
Table 4-39 Clear statistics on encryption card(s)
Operation
Command
Clear statistics on encryption card
reset counters interface encrypt slot-id
III. Deleting SA on encryption card
Use this command to clear the established SAs (either manually or through IKE
negotiation) of the encryption cards on the firewall.
Perform the following configuration in user view.
Table 4-40 Delete SA
Operation
Command
Delete SAs on the encryption cared
reset encrypt-card sa slot-id
Note:
Currently this command is not supported on the encryption card.
4-30
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
IV. Clearing packet statistics on encryption card
You can reset all counters on the encryption card, including those for data packets, byte
counting, lost packets, failed authentication, faulty SAs, invalid SA proposals, invalid
protocols, and so on.
Perform the following configuration in user view.
Table 4-41 Clear packet statistics on encryption card
Operation
Command
Clear packet statistics on encryption card
reset encrypt-card statistics slot-id
Note:
Currently this command is not supported on the encryption card.
V. Clearing system log on encryption card
You can clear the system log, which records all key operations to it, on the encryption
card.
Perform the following configuration in user view.
Table 4-42 Clear system log on encryption card
Operation
Command
Clear system log on encryption card
reset encrypt-card syslog slot-id
Note:
Currently this command is not supported on the encryption card.
VI. Clearing the fast forwarding information on encryption card
Perform the following configuration in user view.
Table 4-43 Clear the fast forwarding information on encryption card
Operation
Command
Clear the fast forwarding information on
the encryption card
4-31
reset encrypt-card fast-switch
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
4.4 Typical IPsec Configuration Example
4.4.1 Establishing SAs Manually
I. Network requirements
Between SecPath A and SecPath B set up a security tunnel to protect the data flows
between the subnets 10.1.1.x and 10.1.2.x where PC A and PC B reside. Set the
security protocol to ESP, and adopt the encryption algorithm DES and the
authentication algorithm SHA1-HMAC-96.
II. Network diagram
SecPathA
SecPathB
Ethernet2/0/1
202.38.163.1
Internet
Ethernet2/0/1
202.38.162.1
10.1.2.1
10.1.1.1
PC A
10.1.1.2
PC B
10.1.2.2
Figure 4-3 IPsec configuration example
III. Configuration procedure
1)
Configure SecPath A:
# Configure an ACL, defining the data flow from the subnet 10.1.1.x to the subnet
10.1.2.x.
[H3C] acl number 3101
[H3C-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[H3C-acl-adv-3101] rule deny ip source any destination any
# Configure a static route to PC B
[H3C] ip route-static 10.1.2.0 255.255.255.0 202.38.162.1
# Create the IPsec proposal named tran1.
[H3C] ipsec proposal tran1
# Set the packet encapsulation mode to tunnel.
[H3C-ipsec-proposal-tran1] encapsulation-mode tunnel
# Set the security protocol to ESP.
[H3C-ipsec-proposal-tran1] transform esp
# Select the encryption and authentication algorithms.
4-32
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
[H3C-ipsec-proposal-tran1] esp encryption-algorithm des
[H3C-ipsec-proposal-tran1] esp authentication-algorithm sha1
# Return to system view.
[H3C-ipsec-proposal-tran1] quit
# Create an IPsec policy and set the negotiation mode to manual.
[H3C] ipsec policy map1 10 manual
# Reference the ACL 3101.
[H3C-ipsec-policy-manual-map1-10] security acl 3101
# Reference the IPsec proposal.
[H3C-ipsec-policy-manual-map1-10] proposal tran1
# Configure the remote address.
[H3C-ipsec-policy-manual-map1-10] tunnel remote 202.38.162.1
# Configure the local address.
[H3C-ipsec-policy-manual-map1-10] tunnel local 202.38.163.1
# Configure SPI.
[H3C-ipsec-policy-manual-map1-10] sa spi outbound esp 12345
[H3C-ipsec-policy-manual-map1-10] sa spi inbound esp 54321
# Configure a key.
[H3C-ipsec-policy-manual-map1-10] sa string-key outbound esp abcdefg
[H3C-ipsec-policy-manual-map1-10] sa string-key inbound esp gfedcba
[H3C-isec-policy-manual-map1-10] quit
# Configure Ethernet2/0/1.
[H3C] interface ethernet 2/0/1
[H3C-Ethernet2/0/1] ip address 202.38.163.1 255.0.0.0
# Apply the IPsec policy group.
[H3C-Ethernet2/0/1] ipsec policy map1
2)
Configure SecPath B
# Configure an ACL, defining the data flow from the subnet 10.1.2.x to the subnet
10.1.1.x.
[H3C] acl number 3101
[H3C-acl-adv-3101] rule permit ip source 10.1.2.0 0.0.0.255 destination
10.1.1.0 0.0.0.255
[H3C-acl-adv-3101] rule deny ip source any destination any
[H3C-acl-adv-3101] quit
# Configure a static route to PC A.
[H3C] ip route-static 10.1.1.0 255.255.255.0 202.38.163.1
4-33
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
# Create the IPsec proposal named tran1.
[H3C] ipsec proposal tran1
# Set the packet encapsulation mode to tunnel.
[H3C-ipsec-proposal-tran1] encapsulation-mode tunnel
# Set the security protocol to ESP.
[H3C-ipsec-proposal-tran1] transform esp
# Select the encryption and authentication algorithms.
[H3C-ipsec-proposal-tran1] esp encryption-algorithm des
[H3C-ipsec-proposal-tran1] esp authentication-algorithm sha1
# Return to system view.
[H3C-ipsec-proposal-tran1] quit
# Create an IPsec policy, setting the negotiation mode to manual.
[H3C] ipsec policy use1 10 manual
# Reference the ACL.
[H3C-ipsec-policy-manual-use1-10] security acl 3101
# Reference the IPsec proposal.
[H3C-ipsec-policy-manual-use1-10] proposal tran1
# Configure the remote address.
[H3C-ipsec-policy-manual-use1-10] tunnel remote 202.38.163.1
# Configure the local address.
[H3C-ipsec-policy-manual-use1-10] tunnel local 202.38.162.1
# Configure SPI.
[H3C-ipsec-policy-manual-use1-10] sa spi outbound esp 54321
[H3C-ipsec-policy-manual-use1-10] sa spi inbound esp 12345
# Configure a key.
[H3C-ipsec-policy-manual-use1-10] sa string-key outbound esp gfedcba
[H3C-ipsec-policy-manual-use1-10] sa string-key inbound esp abcdefg
[H3C-ipsec-policy-manual-use1-10] quit
# Configure Ethernet2/0/1.
[H3C] interface ethernet 2/0/1
# Assign an IP address to the Ethernet interface.
[H3C-Ethernet2/0/1] ip address 202.38.162.1 255.0.0.0
# Apply the IPsec policy group.
[H3C-Ethernet2/0/1] ipsec policy use1
4-34
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
After you complete the configuration, you can set up a security tunnel between the
firewalls SecPath A and SecPath B to allow the data flow to be transmitted encrypted
between the subnets 10.1.1.x and 10.1.2.x.
4.4.2 Establishing ISAKMP SAs
I. Network requirements
As shown in Figure 4-3, between SecPath A and SecPath B set up a security tunnel to
protect the data flow between the subnets 10.1.1.x and 10.1.2.x where PC A and PC B
reside. Set the security protocol to ESP, and adopt the encryption algorithm DES and
the authentication algorithm SHA1-HMAC-96.
II. Network diagram
See Figure 4-3.
III. Configuration procedure
1)
Configure SecPath A:
# Configure an ACL, defining the data flow from the subnet 10.1.1.x to the subnet
10.1.2.x.
[H3C] acl number 3101
[H3C-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[H3C-acl-adv-3101] rule deny ip source any destination any
# Configure a static route to PC B.
[H3C] ip route-static 10.1.2.0 255.255.255.0 202.38.162.1
# Create the IPsec proposal named tran1.
[H3C] ipsec proposal tran1
# Set the packet encapsulation mode to tunnel.
[H3C-ipsec-proposal-tran1] encapsulation-mode tunnel
# Set the security protocol to ESP.
[H3C-ipsec-proposal-tran1] transform esp
# Select the encryption and authentication algorithms.
[H3C-ipsec-proposal-tran1] esp encryption-algorithm des
[H3C-ipsec-proposal-tran1] esp authentication-algorithm sha1
# Return to system view.
[H3C-ipsec-proposal-tran1] quit
# Configure an IKE peer.
[H3C] ike peer peer
4-35
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
[H3C-ike-peer-peer] pre-shared-key abcde
[H3C-ike-peer-peer] remote-address 202.38.162.1
# Create an IPsec policy, setting the negotiation mode to ISAKMP.
[H3C] ipsec policy map1 10 isakmp
# Reference the IPsec proposal.
[H3C-ipsec-policy-isakmp-map1-10] proposal tran1
# Reference the ACL.
[H3C-ipsec-policy-isakmp-map1-10] security acl 3101
# Reference the IKE peer.
[H3C-ipsec-policy-isakmp-map1-10] ike-peer peer
# Return to system view.
[H3C-ipsec-policy-isakmp-map1-10] quit
# Enter the interface view.
[H3C] interface ethernet 2/0/1
# Assign an IP address to the Ethernet interface.
[H3C-Ethernet2/0/1] ip address 202.38.163.1 255.0.0.0
# Apply the IPsec policy group.
[H3C-Ethernet2/0/1] ipsec policy map1
# Return to system view.
[H3C-Ethernet2/0/1] quit
2)
Configure SecPath B:
# Configure an ACL, defining the data flow from the subnet 10.1.2.x to the subnet
10.1.1.x.
[H3C] acl number 3101
[H3C-acl-adv-3101] rule permit ip source 10.1.2.0 0.0.0.255 destination
10.1.1.0 0.0.0.255
[H3C-acl-adv-3101] rule deny ip source any destination any
# Configure the static route to PC A.
[H3C] ip route-static 10.1.1.0 255.255.255.0 202.38.163.1
# Create the IPsec proposal named tran1.
[H3C] ipsec proposal tran1
# Set the packet encapsulation mode to tunnel.
[H3C-ipsec-proposal-tran1] encapsulation-mode tunnel
# Set the security protocol to ESP.
[H3C-ipsec-proposal-tran1] transform esp
4-36
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
# Select the encryption and authentication algorithms.
[H3C-ipsec-proposal-tran1] esp encryption-algorithm des
[H3C-ipsec-proposal-tran1] esp authentication-algorithm sha1
# Return to system view.
[H3C-ipsec-proposal-tran1] quit
# Configure an IKE peer.
[H3C] ike peer peer
[H3C-ike-peer-peer] pre-shared-key abcde
[H3C-ike-peer-peer] remote-address 202.38.163.1
# Create an IPsec policy, setting the negotiation mode to ISAKMP.
[H3C] ipsec policy use1 10 isakmp
# Reference the ACL.
[H3C-ipsec-policy-isakmp-use1-10] security acl 3101
# Reference the IPsec proposal.
[H3C-ipsec-policy-isakmp-use1-10] proposal tran1
# Reference the IKE peer.
[H3C-ipsec-policy-isakmp-map1-10] ike-peer peer
# Return to system view.
[H3C-ipsec-policy-isakmp-use1-10] quit
# Enter the interface view.
[H3C] interface ethernet 2/0/1
# Assign an IP address to the Ethernet interface.
[H3C-Ethernet2/0/1] ip address 202.38.162.1 255.0.0.0
# Apply the IPsec policy group.
[H3C-Ethernet2/0/1] ipsec policy use1
# Return to system view.
[H3C-Ethernet2/0/1] quit
After the configuration is finished, the receipt of a packet from the subnet 10.1.1.x or
10.1.2.x can trigger IKE to negotiate SAs between SecPath A and SecPath B. If the
negotiation is successful, the data flow between the two subnets is transmitted
encrypted.
4-37
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
4.4.3 Implementing Encryption/Decryption and Authentication on
Encryption Card
I. Network requirements
A security tunnel will be configured between SecPath A and SecPath B. Data flow
security protection will be setup between sub-network (10.1.1.0/24) represented by PC
A and sub-network (10.1.2.0/24) represented by PC B. Manually create SAs, choose
ESP protocol, DES encryption algorithm and SHA1-HMAC-96 authentication algorithm.
II. Network diagram
e0/0/0:10.1.2.1
e0/0/0:10.1.1.1
Internet
PC A
10.1.1.2
e3/0/0:202.38.162.1
SecPathB
e3/0/0:202.38.163.1
SecPathA
PC B
10.1.2.2
Figure 4-4 Network diagram for creating SAs over encryption card
III. Configuration procedure
1)
Configure SecPath A
# Configure an access control list, defining data flow from sub-network 10.1.1.0/24 to
sub-network 10.1.2.0/24.
[H3C] acl number 3001
[H3C-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination
10.1.2.0 0.0.0.255
[H3C-acl-adv-3001] rule deny ip source any destination any
# Create SA proposal “tran1”.
[H3C] ipsec card-proposal tran1
# Specify that SA proposal tran1 uses the encryption card on the slot 1/0/0.
[H3C-ipsec-card-proposal-tran1] use encrypt-card 1/0/0
# Packet encapsulation format is tunnel mode.
[H3C-ipsec-card-proposal-tran1] encapsulation-mode tunnel
# Security protocol is ESP.
[H3C-ipsec-card-proposal-tran1] transform esp
# Select algorithm.
[H3C-ipsec-card-proposal-tran1] esp encryption-algorithm des
[H3C-ipsec-card-proposal-tran1] esp authentication-algorithm sha1-hmac-96
4-38
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
# Return to system view.
[H3C-ipsec-card-proposal-tran1] quit
# Establish a security policy and negotiation mode is manual.
[H3C] ipsec policy policy1 10 manual
# Quote access control list.
[H3C-ipsec-policy-policy1-10] security acl 3001
# Configure the peer address.
[H3C-ipsec-policy-policy1-10] tunnel remote 202.38.162.1
# Configure local end address.
[H3C-ipsec-policy-policy1-10] tunnel local 202.38.163.1
# Quote SA proposal.
[H3C-ipsec-policy-policy1-10] proposal tran1
# Configure SPI.
[H3C-ipsec-policy-policy1-10] sa spi outbound esp 12345
[H3C-ipsec-policy-policy1-10] sa spi inbound esp 54321
# Configure key.
[H3C-ipsec-policy-policy1-10] sa string-key outbound esp abcdefg
[H3C-ipsec-policy-policy1-10] sa string-key inbound esp gfedcba
# Return to system view.
[H3C-ipsec-policy-policy1-10] quit
# Enter Ethernet interface view, configure IP address.
[H3C-Ethernet0/0/0] ip address 10.1.1.1 255.255.255.0
[H3C-Ethernet0/0/0] quit
# Enter Ethernet interface view, configure IP address.
[H3C] interface ethernet 3/0/0
[H3C-Ethernet3/0/0] ip address 202.38.163.1 255.255.255.0
# Return to system view, configure a static route to the segment 10.1.2.0/24.
[H3C-Ethernet3/0/0] quit
[H3C] ip route-static 10.1.2.0 255.255.255.0 202.38.162.1
# Apply security policy set on the Ethernet interface.
[H3C-Ethernet3/0/0] ipsec policy policy1
2)
Configure SecPath B
# Configure an access control list, specifying data flow from sub-network 10.1.2.0/24 to
sub-network 10.1.1.0/24.
[H3C] acl number 3000
4-39
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
[H3C-acl-adv-3000] rule permit ip source 10.1.2.0 0.0.0.255 destination
10.1.1.0 0.0.0.255
[H3C-acl-adv-3000] rule deny ip source any destination any
# Create SA proposal “trans1”.
[H3C] ipsec card-proposal tran1
# Specify that SA proposal trans1 uses the encryption card on the slot 1/0/0.
[H3C] use encrypt-card 1/0/0
# Packet encapsulation format is tunnel mode.
[H3C-ipsec-card-proposal-tran1] encapsulation-mode tunnel
# Security protocol is ESP.
[H3C-ipsec-card-proposal-tran1] transform esp
# Select algorithm.
[H3C-ipsec-card-proposal-tran1] esp encryption-algorithm des
[H3C-ipsec-card-proposal-tran1] esp authentication-algorithm sha1-hmac-96
# Return to system view.
[H3C-ipsec-card-proposal-tran1] quit
# Establish a security policy and negotiation mode is manual.
[H3C] ipsec policy map1 10 manual
# Quote access control list.
[H3C-ipsec-policy-map1-10] security acl 3000
# Configure the peer address.
[H3C-ipsec-policy-map1-10] tunnel remote 202.38.163.1
# Configure local end address.
[H3C-ipsec-policy-map1-10] tunnel local 202.38.162.1
# Quote SA proposal.
[H3C-ipsec-policy-map1-10] proposal tran1
# Configure SPI.
[H3C-ipsec-policy-map1-10] sa spi outbound esp 54321
[H3C-ipsec-policy-map1-10] sa spi inbound esp 12345
# Configure key.
[H3C-ipsec-policy-map1-10] sa string-key outbound esp gfedcba
[H3C-ipsec-policy-map1-10] sa string-key inbound esp abcdefg
# Return to system view.
[H3C-ipsec-policy-map1-10] quit
# Enter Ethernet interface view, configure IP address.
4-40
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
[H3C-Ethernet0/0/0] ip address 10.1.2.1 255.255.255.0
[H3C-Ethernet0/0/0] quit
# Enter Ethernet interface view, configure IP address.
[H3C] interface ethernet 3/0/0
[H3C-Ethernet3/0/0] ip address 202.38.162.1 255.255.255.0
# Return to system view, configure a static route to the segment 10.1.1.x.
[H3C-Ethernet3/0/0] quit
[H3C] ip route-static 10.1.1.0 255.255.255.0 202.38.163.1
# Apply security policy set on the Ethernet interface.
[H3C-Ethernet3/0/0] ipsec policy map1
4.4.4 Configuration Example of SA Setup Between a Firewall and the Virtual
Address of a VRRP Standby Group
I. Network requirements
As shown in the following diagram, the headquarters uses the VRRP standby group
formed by SecPath A and SecPath B as its default gateway. SecPath C sets up IPsec
SAs with the virtual address of this VRRP standby group to protect data transmitted
between the headquarters and the branch.
Router A and Router B are access routers of operators. They are not discussed here.
4-41
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
II. Network diagram
12.0.0.1
Host B
Eth1/0/0:12.0.0.2
Branch office
SecPathC
Eth0/0/0:13.0.0.1
Eth0/0/0:13.0.0.4
RouterA
Internet
RouterB
eth1/0/0:10.0.0.4
Eth0/0/0:10.0.0.1
VRRP ID1:10.0.0.5
Eth0/0/0:10.0.0.3
SecPathA
SecPathB
Eth1/0/0:11.0.0.1
Eth1/0/0:11.0.0.3
VRRP ID2:11.0.0.5
Headquarters
11.0.0.7
Host A
Figure 4-5 Set up SAs between a firewall and a virtual address of a VRRP backup
group
III. Configuration procedure
1)
Configure SecPath A
# Configure SecPath A as the master in a VRRP group.
<H3C> system
[H3C] vrrp ping-enable
[H3C] interface ethernet0/0/0
[H3C-Ethernet0/0/0] ip address 10.0.0.1 255.255.255.0
[H3C-Ethernet0/0/0] vrrp vrid 1 virtual-ip 10.0.0.5
[H3C-Ethernet0/0/0] vrrp vrid 1 priority 120
[H3C-Ethernet0/0/0] vrrp vrid 1 preempt-mode timer delay 5
[H3C-Ethernet0/0/0] interface ethernet1/0/0
[H3C-Ethernet1/0/0] ip address 11.0.0.1 255.255.255.0
[H3C-Ethernet1/0/0] vrrp vrid 2 virtual-ip 11.0.0.5
[H3C-Ethernet1/0/0] vrrp vrid 2 priority 120
4-42
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
[H3C-Ethernet1/0/0] vrrp vrid 2 preempt-mode timer delay 5
[H3C-Ethernet1/0/0] quit
# Configure the data flow protected by IPsec.
[H3C] acl number 3101
[H3C-acl-adv-3101] rule 0 permit ip source 11.0.0.0 0.0.0.255 destination
12.0.0.0 0.0.0.255
[H3C-acl-adv-3101] rule deny ip source any destination any
[H3C-acl-adv-3101] quit
# Configure a static route to host B.
[H3C] ip route-static 0.0.0.0 0.0.0.0 10.0.0.4 preference 60
# Configure IPsec DPD.
[H3C] ike dpd dpd1
[H3C-ike-dpd-dpd1] interval-time 10
[H3C-ike-dpd-dpd1] time-out 5
[H3C-ike-dpd-dpd1] quit
# Create a security proposal named tran1 (the contents are omitted).
[H3C] ipsec proposal tran1
#Configure an IKE peer.
[H3C] ike peer peer
[H3C-ike-peer-peer] pre-shared-key abcde
[H3C-ike-peer-peer] remote-address 13.0.0.1
[H3C-ike-peer-peer] local-address 10.0.0.5
[H3C-ike-peer-peer] dpd dpd1
[H3C-ike-peer-peer] quit
# Create a security policy, setting negotiation mode to isakmp.
[H3C] ipsec policy map1 10 isakmp
[H3C-ipsec-policy-isakmp-map1-10] proposal tran1
[H3C-ipsec-policy-isakmp-map1-10] security acl 3101
[H3C-ipsec-policy-isakmp-map1-10] ike-peer peer
[H3C-ipsec-policy-isakmp-map1-10] quit
# Apply an IPsec policy group to the interface.
[H3C] interface ethernet 0/0/0
[H3C-ethernet0/0/0] ipsec policy map1
[H3C-ethernet0/0/0] quit
2)
Configure SecPath B
# Configure SecPath B as a slave in the VRRP standby group. It uses the default
priority 100, lower than that of Router A.
<H3C> system
4-43
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
[H3C] vrrp ping-enable
[H3C] interface ethernet 0/0/0
[H3C-Ethernet0/0/0] ip address 10.0.0.3 255.255.255.0
[H3C-Ethernet0/0/0] vrrp vrid 1 virtual-ip 10.0.0.5
[H3C-Ethernet0/0/0] interface ethernet 1/0/0
[H3C-Ethernet1/0/0] ip address 11.0.0.3 255.255.255.0
[H3C-Ethernet1/0/0] vrrp vrid 2 virtual-ip 11.0.0.5
[H3C-Ethernet1/0/0] quit
# Configure the data flow protected by IPsec.
[H3C] acl number 3101
[H3C-acl-adv-3101] rule 0 permit ip source 11.0.0.0 0.0.0.255 destination
12.0.0.0 0.0.0.255
[H3C-acl-adv-3101] rule deny ip source any destination any
[H3C-acl-adv-3101] quit
# Configure a static route to host B.
[H3C] ip route-static 0.0.0.0 0.0.0.0 10.0.0.4 preference 60
# Configure IPsec DPD.
[H3C] ike dpd dpd1
[H3C-ike-dpd-dpd1] interval-time 10
[H3C-ike-dpd-dpd1] time-out 5
[H3C-ike-dpd-dpd1] quit
# Create a security proposal named tran1 (the contents are omitted).
[H3C] ipsec proposal tran1
# Configure an IKE peer.
[H3C] ike peer peer
[H3C-ike-peer-peer] pre-shared-key abcde
[H3C-ike-peer-peer] remote-address 13.0.0.1
[H3C-ike-peer-peer] local-address 10.0.0.5
[H3C-ike-peer-peer] dpd dpd1
[H3C-ike-peer-peer] quit
# Create an IPsec policy, setting negotiation mode to isakmp.
[H3C] ipsec policy map1 10 isakmp
[H3C-ipsec-policy-isakmp-map1-10] proposal tran1
[H3C-ipsec-policy-isakmp-map1-10] security acl 3101
[H3C-ipsec-policy-isakmp-map1-10] ike-peer peer
[H3C-ipsec-policy-isakmp-map1-10] quit
# Apply a security policy group to the interface.
[H3C] interface ethernet 0/0/0
[H3C-Ethernet0/0/0] ipsec policy map1
4-44
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
[H3C-Ethernet0/0/0] quit
3)
Configure SecPath C
# Configure the data flow protected by IPsec.
[H3C] acl number 3101
[H3C-acl-adv-3101] rule 0 permit ip source 12.0.0.0 0.0.0.255 destination
11.0.0.0 0.0.0.255
[H3C-acl-adv-3101] rule deny ip source any destination any
[H3C-acl-adv-3101] quit
# Configure a static route to host A.
[H3C] ip route-static 0.0.0.0 0.0.0.0 13.0.0.4 preference 60
# Configure IPsec DPD.
[H3C] ike dpd dpd1
[H3C-ike-dpd-dpd1] interval-time 10
[H3C-ike-dpd-dpd1] time-out 5
[H3C-ike-dpd-dpd1] quit
# Create a security proposal named tran1 (the content is omitted).
[H3C] ipsec proposal tran1
# Configure an IKE peer.
[H3C] ike peer peer
[H3C-ike-peer-peer] pre-shared-key abcde
[H3C-ike-peer-peer] remote-address 10.0.0.5
[H3C-ike-peer-peer] local-address 13.0.0.1
[H3C-ike-peer-peer] dpd dpd1
[H3C-ike-peer-peer] quit
# Create a security policy, setting negotiation mode to isakmp.
[H3C] ipsec policy map1 10 isakmp
[H3C-ipsec-policy-isakmp-map1-10] proposal tran1
[H3C-ipsec-policy-isakmp-map1-10] security acl 3101
[H3C-ipsec-policy-isakmp-map1-10] ike-peer peer
[H3C-ipsec-policy-isakmp-map1-10] quit
# Apply an IPsec policy group to the interface.
[H3C] interface ethernet 0/0/0
[H3C-Ethernet0/0/0] ip address 13.0.0.1 255.0.0.0
[H3C-Ethernet0/0/0] ipsec policy map1
[H3C-Ethernet0/0/0] quit
# Configure an Ethernet interface.
[H3C] interface ethernet 1/0/0
[H3C-Ethernet1/0/0] ip address 12.0.0.2 255.255.255.0
4-45
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
Execute the ping -c 500 11.0.0.7 command on host B to ping PC A, and then execute
the display ike sa and display ipsec sa commands on SecPath A and SecPath C
respectively to display established SAs.
Execute the shutdown command on interface Ethernet 0/0/0 on SecPath A. Then
execute the debugging ike dpd command on SecPath C. You may find out that a DPD
query is sent three times, but no acknowledgement is received. Then, all SAs on the
involved peer are deleted, while failover is happening in the VRRP standby group.
About 10 seconds later, the security tunnel is recovered. The following debugging
information is displayed:
<H3C> debugging ike dpd
(SAs are deleted after three DPD query attempts are failed.)
H3C IKE/8/DEBUG:REQUEST(send dpd request): send a message (seqno:-12903966)
H3C IKE/8/DEBUG:REQUEST: wait for response timeout
H3C IKE/8/DEBUG:REQUEST(send dpd request): send a message (seqno:-1917909230
H3C IKE/8/DEBUG:REQUEST: wait for response timeout
H3C IKE/8/DEBUG:REQUEST(send dpd request): send a message (seqno:-1183268982)
H3C IKE/8/DEBUG:REQUEST: wait for response timeout
H3C IKE/8/DEBUG:REQUEST: there are three fail and all SAs associated were
deleted
(A response is received from the peer after the failover completes in its corresponding
VRRP standby group)
H3C IKE/8/DEBUG:REQUEST(send dpd request): send a message (seqno:1382148220)
H3C
IKE/8/DEBUG:REQUEST(recv
dpd
response):
received
a
message
request):
received
a
message
(seqno:1382148220)
H3C
IKE/8/DEBUG:RESPONSE(recv
dpd
(seqno:1382148220)
H3C
IKE/8/DEBUG:RESPONSE(send
dpd
response):
send
a
message
(seqno:1382148220)
4.4.5 IPsec/IKE Multi-Instance Configuration Example
I. Network requirements
CE1 and CE3 belong to VPN1. CE1 and PE1 are connected by an IPsec/IKE tunnel.
CE2 and CE4 belong to VPN2. CE2 and PE1 are connected by an IPsec/IKE tunnel.
4-46
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
II. Network diagram
Eth0/0/1:
32.32.32.2/24
33.33.33.3/24
Eth0/0/0:
21.21.21.2/24
51.51.51.1/24
Eth0/0/0:
21.21.21.1/24
VPN1-CE1
Eth0/0/1:
31.31.31.1/24
Eth0/0/2:
41.41.41.1/24
AS 100
Loopback0:
100.100.100.1/32
51.51.51.2/24
VPN1-CE3
41.41.41.3/24
Loopback0:
100.100.100.2/32
61.61.61.2/24
PE 2
PE 1
61.61.61.1/24
Eth0/0/0:
Eth0/0/1:
34.34.34.2/24 31.31.31.2/24
62.62.62.1/24
VPN2-CE2
VPN2-CE4
Figure 4-6 Network diagram for IPsec/IKE multi-instance configuration
III. Configuration example
1)
Configure CE1
<CE1> system-view
# Configure an IKE peer.
[CE1] ike peer test
[CE1-ike-peer-test] pre-shared-key H3C
[CE1-ike-peer-test] remote-address 21.21.21.1
[CE1-ike-peer-test] quit
# Configure a security proposal (omitted).
[CE1] ipsec proposal prop
# Configure a security policy.
[CE1] ipsec policy map 1 isakmp
[CE1-ipsec-policy-isakmp-map-1] security acl 3000
[CE1-ipsec-policy-isakmp-map-1] ike-peer test
[CE1-ipsec-policy-isakmp-map-1] proposal prop
[CE1-ipsec-policy-isakmp-map-1] quit
# Configure the Ethernet interface and apply the security policy on the interface.
[CE1] interface Ethernet0/0/0
[CE1-Ethernet0/0/0] ip address 21.21.21.2 255.255.255.0
[CE1-Ethernet0/0/0] ipsec policy map
[CE1-Ethernet0/0/0] quit
[CE1] interface Ethernet0/0/1
[CE1-Ethernet0/0/1] ip address 32.32.32.1 255.255.255.0
[CE1-Ethernet0/0/1] quit
# Configure the data flow protected by IPsec.
[CE1] acl number 3000
4-47
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
[CE1-acl-adv-3000] rule 0 permit ip source 21.21.21.0 0.0.0.255 destination
51.51.51.0 0.0.0.255
[CE1-acl-adv-3000] quit
# Configure a static route.
[CE1] ip route-static 0.0.0.0 0.0.0.0 21.21.21.1 preference 60
[CE1] ip route-static 33.33.33.0 255.255.255.0 21.21.21.1 preference 60
2)
Configure PE1
<PE1> system-view
# Configure MPLS basic capability.
[PE1] mpls lsr-id 100.100.100.1
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
# Configure vpn-instance vrf1.
[PE1] ip vpn-instance vrf1
[PE1-vpn-vrf1] route-distinguisher 100:1
[PE1-vpn-vrf1] vpn-target 100:1 export-extcommunity
[PE1-vpn-vrf1] vpn-target 100:1 import-extcommunity
[PE1-vpn-vrf1] quit
# Configure vpn-instance vrf2.
[PE1] ip vpn-instance vrf2
[PE1-vpn-vrf2] route-distinguisher 100:2
[PE1-vpn-vrf2] vpn-target 100:2 export-extcommunity
[PE1-vpn-vrf2] vpn-target 100:2 import-extcommunity
[PE1-vpn-vrf2] quit
# Configure IKE peer test1.
[PE1] ike peer test1
[PE1-ike-peer-test1] pre-shared-key H3C
[PE1-ike-peer-test1] remote-address 21.21.21.2
[PE1-ike-peer-test1] quit
# Configure IKE peer test2.
[PE1] ike peer test2
[PE1-ike-peer-test2] pre-shared-key H3C
[PE1-ike-peer-test2] remote-address 31.31.31.2
[PE1-ike-peer-test2] quit
# Configure a security proposal (the content is omitted).
[PE1] ipsec proposal prop1
[PE1] ipsec proposal prop2
# Configure a security policy.
4-48
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
[PE1] ipsec policy map1 1 isakmp
[PE1-ipsec-policy-isakmp-map1-1] security acl 3000
[PE1-ipsec-policy-isakmp-map1-1] ike-peer test1
[PE1-ipsec-policy-isakmp-map1-1] proposal prop
[PE1-ipsec-policy-isakmp-map1-1] quit
[PE1] ipsec policy map2 1 isakmp
[PE1-ipsec-policy-isakmp-map2-1] security acl 3001
[PE1-ipsec-policy-isakmp-map2-1] ike-peer test2
[PE1-ipsec-policy-isakmp-map2-1] proposal prop2
# Bind the vpn-instance on the interface and apply the security policy on the interface.
[PE1] interface Ethernet0/0/0
[PE1-Ethernet0/0/0] ip binding vpn-instance vrf1
[PE1-Ethernet0/0/0] ip address 21.21.21.1 255.255.255.0
[PE1-Ethernet0/0/0] ipsec policy map1
[PE1-Ethernet0/0/0] quit
[PE1] interface Ethernet0/0/1
[PE1-Ethernet0/0/1] ip binding vpn-instance vrf2
[PE1-Ethernet0/0/1] ip address 31.31.31.1 255.255.255.0
[PE1-Ethernet0/0/1] ipsec policy map2
[PE1-Ethernet0/0/1] quit
# Enable MPLS on Ethernet0/0/2 interface.
[PE1] interface Ethernet0/0/2
[PE1- Ethernet0/0/2] ip address 41.41.41.1 255.255.255.0
[PE1- Ethernet0/0/2] mpls
[PE1- Ethernet0/0/2] mpls ldp enable
[PE1- Ethernet0/0/2] quit
# Configure LoopBack0 interface.
[PE1] interface LoopBack0
[PE1-LoopBack0] ip address 100.100.100.1 255.255.255.255
# Configure the data flow protected by IPsec.
[PE1] acl number 3000
[PE1-acl-adv-3000] rule 0 permit ip source 51.51.51.0 0.0.0.255 destination
21.21.21.0 0.0.0.255
[PE1-acl-adv-3000] quit
[PE1] acl number 3001
[PE1-acl-adv-3001] rule 0 permit ip source 61.61.61.0 0.0.0.255 destination
31.31.31.0 0.0.0.255
[PE1-acl-adv-3001] quit
# Establish the MP-IBGP neighbor between PE1 and PE2. Activate the MP-IBGP peer
in VPNv4 address cluster view.
4-49
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
[PE1] bgp 100
[PE1-bgp] undo synchronization
[PE1-bgp] group g1 internal
[PE1-bgp] peer 100.100.100.2 group g1
[PE1-bgp] peer 100.100.100.2 connect-interface LoopBack0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpn] peer g1 enable
[PE1-bgp-af-vpn] peer 100.100.100.2 group g1
[PE1-bgp-af-vpn] quit
# Configure the private network route importing CE1 and CE2.
[PE1-bgp] ipv4-family vpn-instance vrf1
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn-instance] undo synchronization
[PE1-bgp-af-vpn-instance] quit
[PE1-bgp] ipv4-family vpn-instance vrf2
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn-instance] undo synchronization
[PE1-bgp-af-vpn-instance] quit
# Enable OSPF on the interface connecting PE1 to PE2 and the loop interface to
implement interworking inside the AS.
[PE1] ospf 1
[PE1-ospf-1] area 0.0.0.0
[PE1-ospf-1] network 41.41.41.0 0.0.0.255
[PE1-ospf-1] network 100.100.0.0 0.0.255.255
[PE1-ospf-1] quit
# Configure the static route for the private network.
[PE1] ip route-static vpn-instance vrf1 32.32.32.0 255.255.255.0 21.21.21.2
preference 60
CE2, CE3 and CE4 configuration are similar to CE1 configuration. PE2 configuration is
similar to PE1 configuration.
4.5 IPsec Troubleshooting
Symptom: When apply the IPsec policy on an interface for the first time, the
receive/send end can encrypt and decrypt the data flow; after disabling the IPsec
function, the receive/send end can communicate normally; when apply the IPsec policy
for the second time, packets cannot perform the IPsec process, and the peer end
cannot be pinged successfully.
Troubleshooting: This problem usually appears when the originator configures the
security policy directly in the security policy view, and connected end creates security
policy by importing security policy template. When apply the IPsec policy for the first
4-50
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 4 IPsec Configuration
time, the communication is normally. However, when you disable the function, a fast
switching entry is established at the connected end. So when you enable the IPsec
policy for the second time, the presence of the fast switching entry causes the fail of
IPsec process to the packets. If you use the reset ip fast-forwarding cache command
to clear the fast switching buffer before enable the IPsec policy for the second time, the
problem will be solved.
4-51
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
Chapter 5 IKE Configuration
5.1 IKE Overview
5.1.1 Brief Introduction to IKE
IKE (Internet Key Exchange) is Internet shared secret exchange protocol. It is a mixed
protocol, configured in a framework specified by Internet Security Association and Key
Management Protocol (ISAKMP). IKE will provide automatic negotiation and exchange
of shared key for IPsec and configure Security Association, thus to simplify IPsec
application and management.
Network security has 2 meanings: one is internal LAN security, the other is external
data exchange security. The former is implemented by means of Firewall, network
address translation (NAT) etc. Emerging IPsec (IP security) implements the latter.
IPsec Security Association can be established by manual configuration, but when
nodes increase in the network, manual configuration will be very difficult, and hard to
ensure security. In this case, the IKE automatic negotiation can be used to establish
Security Association and exchange shared secret.
IKE has a series of self-protection mechanisms to safely distribute shared key,
authenticate identity, and establish IPsec Security Association etc. in unsecured
network.
IKE security mechanism includes:
z
Diffie-Hellman (DH) exchange and shared key distribution
Diffie-Hellman algorithm is a shared key algorithm. The both parties in communication
can exchange some data without transmitting shared key and find the shared key by
calculation. The pre-condition for encryption is that the both parties must have shared
key. The merit of IKE is that it never transmits shared key directly in the unsecured
network, but calculates the shared key by exchanging a series data. Even if the third
party (such as Hackers) captured all exchange data used to calculate shared key for
both parties, he cannot figure out the real shared key.
z
Perfect Forward Secrecy (PFS)
PFS feature is a security feature. When a shared key is decrypted, there will be no
impact on the security of other shared keys, because these secrets have no derivative
relations among them. IPsec is implemented by adding one key exchange during IKE
negotiation phase II.
z
Identity authentication
Identity authentication will authenticate identity for both parties in communication.
Authentication key can input to generate shared secret. It is impossible for different
5-1
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
authentication keys to generate the same shared secret between the two parties.
Authentication key is the key in identity authentication for both parties.
z
Identity protection
After shared secret is generated, identity data will be encrypted and transmitted, thus
implementing identity data protection.
IKE using 2 stages to implement shared secret negotiation for IPsec and creating
Security Association. In the first stage, parties involved in the communication will
establish a channel for identity authentication and security protection. An ISAKMP
Security Association (ISAKMP SA) is established by the exchange in this stage. In the
second stage, security channel established in phase 1 will be used to negotiate specific
Security Association for IPsec and establish IPsec SA. IPsec SA will be used for final IP
data security transmission.
The relation between IKE and IPsec is shown in the following figure.
SA negotiation
IKE
IKE
SecPathA
SecPathB
TCP/UDP
SA
SA
IPSec
TCP/UDP
IPSec
IP
Encry pted IP packet
Figure 5-1 Relation between IKE and IPsec
I. IKE aggressive mode
ADSL and dial-up mode are two solutions widely adopted at present in VPN
construction. In these two solutions, there is an exceptional case where IP addresses of
the devices at central office end are static and the IP addresses of the devices at
subscriber end are dynamic. In order to support the application in this special case,
aggressive mode is introduced in IKE negotiation. This mode allows IKE to search for
the pre-shared key of the negotiation initiator by the IP address or ID of the negotiation
initiator to accomplish the negotiation. Compared to the main mode, IKE aggressive
mode allows of more flexibility and supports IKE negotiation even when the IP address
of the initiator is dynamic.
5-2
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
II. NAT traversal
If there is a NAT GW on the VPN tunnel set up via IPsec/IKE and if this GW performs
NAT on the VPN service data, you must configure the NAT traversal function for
IPsec/IKE. With this function, the IKE negotiation will not authenticate the UDP port
number. At the same time, traversal allows NAT GW discovery on the VPN tunnel. If a
NAT GW is discovered, UDP encapsulation will be used in the subsequent IPsec data
transmission, i.e., encapsulating IPsec packets in the UDP connection tunnel for IKE
negotiation), to prevent the NAT GW from modifying the IPsec packets. That is, the NAT
GW will change the outermost IP and UDP headers but leave the IPsec packets
encapsulated in the UDP packets intact, thus ensuring the integrity of the IPsec packets.
The authentication process of an IPsec data encryption/decryption requires the IPsec
packet to arrive at the destination intact. Currently NAT traversal is available in
aggressive mode, but not in main mode.
Usually the two features described above are used together in the ADSL + IPsec
networking to solve the problems resulted from dynamic IP addresses on
broadband-access enterprise networks and NAT traversal on the public network. The
combination of these two features provides a security solution for substituting the ADSL
broadband access for the original leased line access.
III. IKE multi-instance
You can use IKE multi-instance to implement IKE packet negotiation between different
CEs and a PE. The IKE multi-instance and IPsec can implement IPsec/IKE
multi-instance function bound to the interface connecting the PE and CE.
When the CE initiates IKE negotiation, the information about the VPN instance in the IP
packet is sent to the PE. After receiving the information, the PE saves the VPN ID
during negotiation. When sending a negotiation IP packet to the CE, the PE fills the
VPN ID in the IP packet, and then forwards the packet to the IP layer for processing.
The IP layer forwards the packet to the corresponding CE according to the VPN routing
table.
5.1.2 Preparation for IKE Configuration
Prior to IKE configuration, user needs to specify following subjects, so as to smooth the
configuration process:
z
Make clear of algorithm strength for IKE exchange process, i.e., security
protection strength (including identity authentication method, encryption algorithm,
and authentication-algorithm algorithm, DH algorithm). There are different
algorithm strengths. The higher strength the algorithm has, the harder it is to
decrypt the protected data, but more calculation resource will be consumed.
Generally, the longer the shared secret is, the higher the algorithm strength is.
z
Make sure of the identity authentication key of both sides in communication.
5-3
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
5.2 IKE Configuration
5.2.1 Introduction to IKE Configuration
IKE configuration includes:
1)
Set a name for the local security GW
2)
Define IKE proposal
z
Establish IKE Proposal
z
Select encryption algorithm
z
Select authentication method
z
Select authentication algorithm
z
Select Diffie-Hellman Group ID
z
Set lifetime of ISAKMP SA (optional)
3)
Configure IKE peer
z
Create an IKE peer
z
Configure IKE negotiation mode
z
Configure identity authentication key (pre-shared key)
z
Configure ID type in IKE negotiation
z
Configure IP address in IKE negotiation
z
Configure NAT traversal
z
Configure subnet type of the IKE peer
4)
Configure the parameters of Keepalive timer
z
Configure interval for Keepalive transmission
z
Configure timeout time for Keepalive
5.2.2 Setting a Name for the Local Security GW
If the initiator uses the GW name in IKE negotiation (that is, id-type name is used), you
must configure the ike local-name command on the local device.
Perform the following configuration in system view.
Table 5-1 Configure name of the local security GW
Operation
Command
Configure name of the local security GW.
ike local-name name
Restore the default name of the local security GW.
undo ike local local-name
5.2.3 Defining IKE Proposal
I. Establishing IKE Proposal
IKE proposal defines a set of attributes describing how IKE negotiation conducts
security communications. Configuring an IKE proposal includes the tasks of IKE
5-4
Operation Manual – VPN
H3C SecPath Series Security Products
proposal
creation,
selection
Chapter 5 IKE Configuration
in
encryption
algorithm,
authentication
mode,
authentication algorithm, and Diffie-Hellman group ID, and SA lifetime duration setting.
As for main mode, the user may create multiple IKE proposals on the basis of
preference, but the negotiation parties should have at least one matched IKE proposal
in order to reach an agreement. As for aggressive mode, the sponsor negotiates with
the counter party only by selecting the security proposal with the highest preference.
The agreement of negotiation will be reached If the counter party has the matched
security proposal, or the negotiation will fail. That is to say, the sponsor will not hold the
negotiation using security proposal with low preference any more.
This configuration is used to define an IKE proposal. The IKE proposal configured is
used to establish the security channel.
Perform the following configuration in system view.
Table 5-2 Establish IKE proposal
Operation
Command
Create IKE proposal
ike proposal proposal-number
Delete IKE proposal
undo ike proposal proposal-number
Execute the ike proposal command to enter the IKE proposal view, where you can
configure the encryption algorithm, authentication algorithm, Diffie-Hellman group ID,
sa duration, and authentication method.
The parameter proposal-number is the IKE proposal number, ranging from 1 to 100.
This parameter also stands for the priority. A smaller number stands for a higher priority.
You can create multiple IKE proposals for each side of the negotiation. Both side in the
negotiation matches the proposal from the one with the highest priority. There must be
at least one matched policy for successful negotiation, that is, both side must have the
same encryption and authentication algorithm, some authentication method and
Diffie-Hellman group ID.
The system provides a default IKE proposal, which has the lowest priority and has the
default encryption algorithm, authentication algorithm, Diffie-Hellman group ID, SA
duration, and authentication method. The parameters needed by an IKE proposal are
as follows.
II. Selecting Encryption Algorithm
This configuration is used to specify an encryption algorithm used by an IKE proposal.
Perform the following configuration in IKE proposal view.
5-5
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
Table 5-3 Select encryption algorithm
Operation
Command
Select encryption algorithm
encryption-algorithm { des-cbc |
3des-cbc | aes-cbc }
Set the encryption algorithm to the
default value
undo encryption-algorithm
By default, the 56-bit DES algorithm in CBC mode is adopted.
III. Selecting authentication method
This configuration is used to specify an authentication method used by an IKE
proposal.
IKE authentication has two algorithms: pre-share-key and PKI (rsa-signature).
The authentication key must be configured when using the authentication method of
pre-shared key. (Refer to the part of “Configuring pre-shared key”)
Perform the following configuration in IKE proposal view.
Table 5-4 Specify authentication method
Operation
Command
Specify authentication method
authentication-method { pre-share |
rsa-signature }
Restore the authentication method to
the default value
undo authentication-method
By default, pre-share key algorithm is adopted.
Note:
z
Refer to the “PKI Configuration” part of this manual for detailed PKI configurations.
z
In an IKE negotiation, if the initiator uses the rsa-signature authentication method,
the id-type and remote-name command configured in the IKE peer will not take
effect. The responder selects an IKE peer according to the remote-address
configured in IKE peer. So, if rsa-signature authentication method is adopted, both
the initiator and responder should specify the remote-address, otherwise, all
addresses are matched by default.
5-6
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
IV. Selecting Authentication Algorithm
This configuration is used to specify the authentication algorithm used by an IKE
proposal.
Perform the following configuration in IKE proposal view.
Table 5-5 Select authentication algorithm
Operation
Command
Select authentication algorithm
authentication-algorithm { md5 | sha }
Set authentication algorithm to the
default value
undo authentication-algorithm
By default SHA-1 authentication algorithm is adopted.
V. Selecting Diffie-Hellman Group ID
This configuration is used to specify the Diffie-Hellman group ID used by an IKE
proposal.
Perform the following configuration in IKE proposal view.
Table 5-6 Select Diffie-Hellman group ID
Operation
Command
Select Diffie-Hellman group ID
dh { group1 | group2 | group5 | group14 }
Restore the default value of
Diffie-Hellman group ID
undo dh
By default, 768-bit Diffie-Hellman group (group 1) is selected.
VI. Configuring lifetime of ISAKMP SA (optional)
This configuration is used to specify the lifetime of ISAKMP SA used by an IKE
proposal.
Perform the following configuration in IKE proposal view.
Table 5-7 Set sa duration of IKE SA
Operation
Command
Configure lifetime of IKE SA.
sa duration seconds
Restore the default lifetime.
undo sa duration
If sa duration expires, the ISAKMP SA will automatically update. The SA lifetime can
be set as one number between 60 and 604800 seconds. Because the IKE negotiation
5-7
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
needs to perform DH algorithm, which will take a longer period of time. For the purpose
that the update of ISAKMP SA does not affect the security communication, it is
recommended to set the sa duration greater than 10 minutes.
The SA will negotiate another one to replace the old SA before the set SA duration is
exceeded. It is called soft timeout. The starting time of the soft timeout is 90% of the SA
duration timeout. The old SA will be cleared automatically when the SA duration is
exceeded, which can be called hard timeout.
By default, the ISAKMP SA duration is 86400 seconds (a day).
5.2.4 Configuring IKE Peer
I. Creating an IKE peer
Perform the following configuration in system view.
Table 5-8 Configure IKE peer
Operation
Command
Configure an IKE peer and access the
IKE peer view.
ike peer peer-name
Delete the IKE peer.
undo ike peer peer-name
II. Configuring IKE negotiation mode
Perform the following configuration in IKE-peer view.
Table 5-9 Configure negotiation mode
Operation
Command
Configure IKE negotiation mode
exchange-mode { aggressive | main }
Restore the default IKE negotiation
mode
undo exchange-mode
By default, the main mode is adopted.
Note:
z
If the IP address of one end of a security tunnel is dynamic, you must adopt the
aggressive mode for IKE negotiation.
z
If the peer accepts the request using policy template, it selects the negotiation mode
according to the negotiation mode of the initiator.
5-8
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
III. Configuring pre-shared key
Perform the following configuration in IKE-peer view.
Table 5-10 Configure pre-shared key
Operation
Command
Configure a pre-shared key for IKE negotiation.
pre-shared-key key
Remove the pre-shared key used in IKE negotiation.
undo pre-shared-key
IV. Configuring ID type in IKE negotiation
Perform the following configuration in IKE-peer view.
Table 5-11 Configure ID type in IKE negotiation
Operation
Command
Select ID type in the IKE negotiation.
id-type { ip | name }
Restore the default ID type in the IKE negotiation.
undo id-type
By default, IP address is taken as the ID in IKE negotiation.
In main mode, only IP address can be taken as the ID in IKE negotiation. In aggressive
mode, however, you may use either IP address or name as the ID in IKE negotiation.
V. Specifying name of the remote device
If the initiator uses its GW name in IKE negotiation (that is, id-type name is used), it
sends the name to the peer as its identity, whereas the peer uses the username
configured using the remote-name name command to authenticate the initiator. To
pass authentication, this remote name must be the same one configured using the ike
local-name command on the gateway at the initiator end.
Perform the following configuration in IKE-peer view.
Table 5-12 Specify name of the remote device
Operation
Command
Specify the name of a remote device.
remote-name name
Remove the name of the remote device.
undo remote-name
VI. Configuring IP addresses of the local security GW and remote device
If the initiator uses its IP address in IKE negotiation (that is, id-type ip is used), it sends
its IP address to the peer as its identity, whereas the responder uses the address
5-9
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
configured using the remote-address low-ip-address [ high-ip-address ] command to
authenticate the initiator. If only the low-ip-address argument is configured on the
responder, it should be the same as the one configured using the local-address
command on the initiator; if low-ip-address and high-ip-address are all configured on
the responder (that is, an address range is specified), this address range should
include the IP address configured using the local-address command on the initiator.
The initiator of an IKE negotiation cannot specify an address range using the
remote-address command.
Perform the following configuration in IKE-peer view.
Table 5-13 Configure IP address of the local security GW and remote device
Operation
Command
Configure IP address of the local security GW.
local-address ip-address
Delete IP address of the local security GW
undo local-address
Configure IP address of the remote device.
remote-address low-ip-address
[ high-ip-address ]
Delete the IP address of the remote device.
undo remote-address
Generally speaking, you do not need to configure the local-address command unless
you want to specify a special address for the local GW (such as the address of
loopback interface).
VII. Configuring NAT traversal
The NAT traversal function must be configured so long as there is a NAT IPsec device
on the VPN tunnel constructed using IPsec/IKE.
Perform the following configuration in IKE-peer view.
Table 5-14 Configure the NAT traversal function of IPsec/IKE
Operation
Command
Enable the NAT traversal function of IPsec/IKE.
nat-traversal
Disable the NAT traversal function of IPsec/IKE.
undo nat-traversal
To save IP address space, ISPs often deploy NAT gateways on public networks so that
private IP addresses can be allocated to users. The likelihood thus exists that at one
end of an IPsec/IKE tunnel is a public address and at the other end is a private one. To
set up the tunnel in this case, you must configure NAT traversal at both ends of the
tunnel.
5-10
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
VIII. Configuring subnet type of the IKE peer
You can use these two commands only when your firewall is interoperable with a
Netscreen device.
Perform the following configuration in IKE-peer view:
Table 5-15 Configure subnet type of the IKE peer
Operation
Command
Configure subnet type of the local GW
local { multi-subnet | single-subnet }
Restore the default subnet type of the
local GW
undo local
Configure subnet type of the peer GW
peer { multi-subnet | single-subnet }
Restore the default subnet type of the
peer GW
undo peer
The default subnet type of the local GW and peer GW is single-subnet.
5.2.5 Configuring Keepalive Timer
I. Configuring keepalive interval
Configure time interval for ISAKMP SA to transmit hold packet to the peer.
Perform the following configuration in system view.
Table 5-16 Configure time interval for Keepalive packet transmission
Operation
Command
Configure time interval for ISAKMP SA
to transmit Keepalive packet to the peer
ike sa keepalive-timer interval
seconds
Disable the above function
undo ike sa keepalive-timer interval
IKE will maintain the ISAKMP SA link state through this packet. Generally, if the peer
has used the ike sa keepalive-timer timeout command to configure timeout time, this
Keepalive interval must be configured on local end. When the ISAKMP SA on the peer
does not have a timeout flag if the configured timeout time expires, it will be added with
a timeout flag. When the peer receives the Keepalive packets sent from local end again
after the timeout time expires, the timeout flag will be cleared; if the ISAKMP SA on the
peer has a timeout flag, it indicates that no Keepalive packet is received within the
configured timeout time, and this ISAKMP SA and its corresponding IPsec SA will be
deleted. Therefore, the configured timeout time should be longer than Keepalive packet
transmission time.
By default, this function is invalid.
5-11
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
II. Configuring keepalive timeout time
Configure timeout time for ISAKMP SA waiting for Keepalive packet.
Perform the following configuration in system view.
Table 5-17 Configure timeout waiting time for Keepalive packet
Operation
Command
Configure ISAKMP SA timeout time for
waiting Keepalive packet
ike sa keepalive-timer timeout
seconds
Disable this function
undo ike sa keepalive-timer timeout
IKE maintains this ISAKMP SA link status through this packet. When the ISAKMP SA
on the peer does not have a timeout flag if the configured timeout time expires, it will be
added with a timeout flag. When the peer receives the Keepalive packets sent from
local end again after the timeout time expires, the timeout flag will be cleared; if the
ISAKMP SA on the peer has a timeout flag, it indicates that no Keepalive packet is
received within the configured timeout time, and this ISAKMP SA and its corresponding
IPsec SA will be deleted. Therefore, configured timeout time should be longer than
Keepalive packet transmission time.
On the network, packet loss will rarely exceed 3 times, so timeout time can be
configured to be 3 times as long as Keepalive packet transmission time interval of the
peer.
By default, this function is invalid.
III. Configuring Keepalive sending interval
Perform the following configuration in system view.
Table 5-18 Configure Keepalive sending interval
Operation
Command
Define the time interval for the IKE peer to
send NAT Keepalive packets.
ike sa nat-keepalive-timer
interval seconds
Restore the default time interval for the IKE
peer to send NAT Keepalive packets.
undo ike sa nat-keepalive-timer
interval
By default, the time interval for the IKE peer to send NAT Keepalive packets is 20
seconds.
The NAT gateway sends NAT Keepalive packets to maintain dynamic mapping
between IKE peers, but not to detect the status of the peers. When defining the timer
interval, ensure that the time interval is less than the timeout time for NAT translation.
5-12
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
5.2.6 Disabling IKE DH Hardware Acceleration
The firewall supports IKE DH hardware acceleration. You can switch to software
processing when the encryption card becomes faulty.
Perform the following configuration in system view.
Table 5-19 Disable/enable IKE DH hardware acceleration
Operation
Command
Disable IKE DH hardware acceleration.
ike encrypt-card dh-computation
disabled
Enable IKE DH hardware acceleration.
undo ike encrypt-card
dh-computation disabled
By default, IKE DH hardware acceleration is enabled.
Note:
DH switching uses software processing when IKE DH hardware acceleration is
disabled, so system performance may be degraded.
5.3 Displaying and Debugging IKE
After the above configuration, execute display command in all views to display the
running of the IKE configuration, and to verify the effect of the configuration.
Execute debugging and reset commands in user view.
Table 5-20 Display and debug IKE
Operation
Command
Display the current established
security channel
display ike sa [ verbose [ connection-id
id | remote-address ip-address ] ]
Display the parameters of each IKE
proposal configuration.
display ike proposal
Display the configuration of IKE peers
display ike peer [ peer-name ]
Delete a security channel
reset ike sa [ connection-id ]
Enable the information debugging of
IKE
debugging ike { all | error | exchange |
message | misc| transport }
Disable the information debugging of
IKE
undo debugging ike { all | error |
exchange | message | misc| transport }
5-13
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
You can delete a specified security channel by specifying SA connection-id which can
be displayed by executing the display ike sa command. So far as the same security
channel (that is, the same remote end) is concerned, the connection-id information
includes the information at stage 1 and the information at stage 2.
If the ISAKMP SA at stage 1 still exists when you deleting the local SA, the system will
send the DELETE message in the protection mode of the ISAKMP SA to notify the peer
to clear the SA database.
If no connection-id is specified, all the SAs at stage 1 will be removed.
Security channel and SA are totally different concepts. Security channel is a channel
via which its two endpoints can make bidirectional communications but IPsec SA is just
a unidirectional connection. In other words, security channel comprises a pair or
several pairs of SAs.
5.4 Typical Configuration of IKE
5.4.1 Typical IKE Configuration Example
I. Network requirements
z
Hosts 1 and 2 communicate securely, and a security channel is established with
IKE automatic negotiation between security SecPath A and B.
z
Configure an IKE proposal assigned with the priority level 10 on the security
SecPath A and apply the default IKE proposal on the security SecPath B.
z
Configure authentication key for the proposal using the pre-shared key
authentication method.
II. Network diagram
Ethernet 2/0/1
171.69.224.33
Ethernet 2/0/1
202.38.160.1
Internet
SecPathA
Ethernet
SecPathB
Ethernet
202.39.1.0
172.70.2.0
Host 1
Host 2
Figure 5-2 Network diagram of IKE configuration example
III. Configuration procedure
1)
Make the following configurations on the SecPath A:
# Configure an IKE peer.
5-14
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
[H3C] ike peer peer
[H3C-ike-peer-peer] pre-shared-key abcde
[H3C-ike-peer-peer] remote-address 171.69.224.33
# Configure an IKE proposal 10.
[H3C] ike proposal 10
# Set the authentication algorithm used by the IKE proposal to MD5.
[H3C-ike-proposal-10] authentication-algorithm md5
# Apply the pre-shared key authentication mode.
[H3C-ike-proposal-10] authentication-method pre-share
# Set the lifetime duration of ISAKMP SA to 5000 seconds.
[H3C-ike-proposal-10] sa duration 5000
2)
Make the following configurations on the SecPath B:
# Configure an IKE peer.
[H3C] ike peer peer
[H3C-ike-peer-peer] pre-shared-key abcde
[H3C-ike-peer-peer] remote address 202.38.160.1
The configurations made above can ensure the proper IKE negotiation between
SecPath A and B. As SecPath A is configured with proposal 10 and
authentication-algorithm md5 but SecPath B is configured with only a default IKE
proposal and authentication-algorithm sha, SecPath B will not have a proposal
matching the IKE proposal 10 configured on SecPath A. For this reason, the system will
find only a match, that is, the default IKE proposal for the both parties when it makes the
match operation in proposals starting from the one with the highest priority. In addition,
no match operation will be done on duration in the proposal matching process, as the
lifetime is decided by the initiator of IKE negotiation.
For more information about IPsec configurations, see “Typical IPsec Configuration
Examples” in Chapter 5.
5.4.2 Typical IKE Aggressive Mode and NAT Traversal Configuration
Example
I. Network requirements
z
The Ethernet0/0/0 interface of SecPath A has a fixed IP address in public network
and SecPath B obtains IP address dynamically.
z
Since SecPath B can only access public network through NAT devices of service
provider, so a company branch has to obtain IKE aggressive mode and NAT
traversal function to set up IPsec connection.
z
To ensure information security, IPsec/IKE is adopted to create a security tunnel.
5-15
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
II. Network diagram
Branch
Internet
E0/0/0
Headquarters
E0/0/0
SecPathB
SecPathA
Figure 5-3 Network application of IKE aggressive mode and NAT traversal
III. Configuration procedure
1)
Configure SecPath A
# Set a name for the local security GW.
[H3C] ike local-name SecPathA
# Configure ACL.
[H3C] acl number 3101 match-order auto
[H3C-acl-adv-3101] rule permit ip source any destination any
# Configure an IKE peer.
[H3C] ike peer peer
[H3C-ike-peer-peer] exchange-mode aggressive
[H3C-ike-peer-peer] pre-shared-key abc
[H3C-ike-peer-peer] id-type name
[H3C-ike-peer-peer] remote-name SecPathB
[H3C-ike-peer-peer] nat traversal
# Create an IPsec proposal “prop”.
[H3C] ipsec proposal prop
[H3C-ipsec-proposal-prop] encapsulation-mode tunnel
[H3C-ipsec-proposal-prop] transform esp
[H3C-ipsec-proposal-prop] esp encryption-algorithm des
[H3C-ipsec-proposal-prop] esp authentication-algorithm sha1
# Create an IPsec policy and establish an SA through IKE negotiation.
[H3C] ipsec policy policy 10 isakmp
# Configure the IPsec policy and quote the IKE peer in the policy.
[H3C-ipsec-policy-isakmp-policy-10] ike-peer peer
# Quote the ACL 3101 in the IPsec policy.
[H3C-ipsec-policy-isakmp-policy-10] security acl 3101
# Quote the IPsec proposal “prop” in the IPsec policy.
[H3C-ipsec-policy-isakmp-policy-10] proposal prop
# Access the interface E0/0/0 and configure its IP address.
5-16
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
[H3C] interface Ethernet0/0/0
[H3C-Ethernet0/0/0] ip address 10.0.0.1 255.255.0.0
# Apply the IPsec policy group “policy” on the interface E0/0/0.
[H3C-Ethernet0/0/0] ipsec policy policy
2)
Configure SecPath B
# Set a name for the local security GW.
[H3C] ike local-name SecPathB
# Configure ACL.
[H3C] acl number 3101 match-order auto
[H3C-acl-adv-3101] rule permit ip source any destination any
# Configure an IKE peer.
[H3C] ike peer peer
[H3C-ike-peer-peer] exchange-mode aggressive
[H3C-ike-peer-peer] pre-shared-key abc
[H3C-ike-peer-peer] id-type name
[H3C-ike-peer-peer] remote-name SecPathA
[H3C-ike-peer-peer] remote-address 10.0.0.1
[H3C-ike-peer-peer] nat traversal
# Create an IPsec proposal “prop”.
[H3C] ipsec proposal prop
[H3C-ipsec-proposal-prop] encapsulation-mode tunnel
[H3C-ipsec-proposal-prop] transform esp
[H3C-ipsec-proposal-prop] esp encryption-algorithm des
[H3C-ipsec-proposal-prop] esp authentication-algorithm sha1
# Create an IPsec policy and specify to set up SA by means of IKE negotiation.
[H3C] ipsec policy policy 10 isakmp
# Quote the IKE peer in the IPsec policy.
[H3C-ipsec-policy-isakmp-policy-10] ike-peer peer
# Quote the ACL 3101 in the IPsec policy.
[H3C-ipsec-policy-isakmp-policy-10] security acl 3101
# Quote the IPsec proposal “prop” in the IPsec policy.
[H3C-ipsec-policy-isakmp-policy-10] proposal prop
# Access the interface E0/0/0 and assign a dynamic IP address to the interface.
[H3C-Ethernet0/0/0] pppoe-client dial-bundle-number 1
# Configure dial-up interface.
[H3C] dialer-rule 1 ip permit
[H3C] interface dialer 1
5-17
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
[H3C-Dialer1] link-protocol ppp
[H3C-Dialer1] ppp pap local-user aaa password simple aaa
[H3C-Dialer1] mtu 1450
[H3C-Dialer1] ip address ppp-negotiate
[H3C-Dialer1] dialer user 12
[H3C-Dialer1] dialer-group 1
[H3C-Dialer1] dialer bundle 1
# Apply the IPsec policy group “policy” on the interface Dialer 1.
[H3C-Dialer1] ipsec policy policy
5.5 IKE Fault Diagnosis and Troubleshooting
When configuring parameters to establish IPsec security channel, you can enable the
Error debugging of IKE to help us find configuration problems. The command is as
follows:
<H3C> debugging ike error
Symptom 1: Invalid user ID information
Troubleshooting: User ID is the data that the user initiating the IPsec communication
uses to identify itself. In actual applications, you can make use of user ID to set up
different security channels for various types of data traffic for the sake of protection. In
the implementation of H3C Technology, a user is so far identified by its IP address.
Following is the debugging information you may view on the screen:
got NOTIFY of type INVALID_ID_INFORMATION
Or
drop message from A.B.C.D due to notification type INVALID_ID_INFORMATION
Check whether the ACLs of the IPsec policies configured on the interfaces at both ends
of the negotiation are compatible. The user is recommended to configure the ACLs to
mirror each other. For more information about ACL mirror, refer to Section Configure
ACL in IPsec Configuration.
Symptom 2: Proposal mismatch
Troubleshooting:
Following is the debugging information you may view on the screen:
got NOTIFY of type NO_PROPOSAL_CHOSEN
Or
drop message from A.B.C.D due to notification type NO_PROPOSAL_CHOSEN
The two parties of the negotiation have no matched proposal. For the negotiation at
stage 1, you can look up the IKE proposals for a match. For the negotiation at stage 2,
you can check whether the parameters of the IPsec polices applied on the interfaces
5-18
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 5 IKE Configuration
are matched, and whether the referenced IPsec proposals have a match in protocol,
encryption and authentication algorithms.
Symptom 3: Unable to establish security channel
Troubleshooting: Check whether the network is stable and the security channel is
established correctly. Sometimes there is a security channel but there is no way to
communicate, and ACL of both parties are found correctly configured, and there is also
matched policy.
In this case, the problem is usually cased by the restart of one firewall after the security
channel is established. Solution:
z
Use the command display ike sa to check whether both parties have established
SA of Phase 1.
z
Use the command display ipsec sa to check whether the ipsec policy on interface
has established IPsec SA.
z
If the above two results display that one party has SA but the other does not, then
use the command reset ike sa to clear SA with error and re-originate negotiation.
5-19
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
Chapter 6 DVPN Configuration
6.1 Introduction to DVPN
6.1.1 Overview
Dynamic virtual private network (DVPN) technology is a kind of technology that
establishes virtual private networks (VPN) by dynamically acquiring the information
about the peers. DVPN adopts a NBMA-type tunnel mechanism, which enables
devices to encapsulate and transmit packets with tunnel interfaces as the end points of
DPVN tunnels and enables devices to learn routes of private networks through tunnel
interfaces dynamically. (NBMA: non-broadcast multiple access)
DVPN technology also adopts a client-server model to overcome the drawbacks that
the traditional VPN technology suffers from. By registering with a server, clients store
their information on the server. So a registered client can then acquire information
about other registered clients through the redirecting function the server provides to
establish separate sessions with corresponding clients. By registering with the same
server, multiple DVPN-enabled access devices can form a DVPN domain to have
VPNs connected to these access devices interconnected.
6.1.2 Basic DVPN Elements
I. DVPN domain
A set of private networks and their firewalls and routers that are interconnected using
DVPN.
II. DVPN access device
Routers or firewalls in a network that are used to form DVPN domains. Any router or
firewall that supports DVPN technology can be a DVPN access device.
III. DVPN server
DVPN access device that operates as the server in a DVPN domain. DVPN access
devices must register with the DVPN server before they can access a DVPN domain.
Functions of DVPN severs are as follows.
z
Storing and maintaining registering information about DVPN clients
z
Authenticating clients that apply for accessing the DVPN domain
z
Forwarding packets between clients with no sessions established in between, and
sending redirecting packets to source clients
z
Encrypting packets using IPsec
6-1
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
IV. DVPN client
DVPN access device that operates as client in a DVPN domain. A device must
successfully register with the DVPN server to access a DVPN domain. Functions of
DVPN client are as follows.
z
Registering with the DVPN server to join a DVPN domain
z
Establishing sessions with DVPN servers for data transmission
z
Establishing sessions with other DVPN clients in the DVPN domain
z
Encrypting packets using IPsec
V. DVPN ID
Identifier of a DVPN domain. For a DVPN access device, different DVPN domains have
different DVPN IDs.
VI. Map
Channel established between a DVPN client and a DVPN server when the DVPN client
attempts to register with the DVPN server. A map remains after the client successfully
registers with the DVPN server until the DVPN client exit the DVPN domain or the
network. The information a map holds, such as the ID of the DVPN domain, the private
IP address of the peer, the public IP address of the peer, the UDP port number used,
the state of the map, and the control ID, is stored in both the client side and the DVPN
server side.
VII. Session
DVPN tunnel for data transmission. In a DVPN domain, sessions are established
between pairs of DVPN access devices and are used to connect private networks.
Packets in a DVPN domain are transmitted through sessions. The information a
session contains is similar to that of a map, such as the ID of the DVPN domain, the
private and public IP address of the peer, UDP port number used, the state of the
session, and the type of the session.
VIII. Redirect
Redirecting mechanism. For two clients with no session in between, communications
between them are carried out by the DVPN server. When forwarding packets between
these two clients, the DVPN server sends redirecting packets to the source client if the
DVPN server determines a separate session can be established between the two
clients. Redirecting packets contain information about the destination clients and
enable sessions to be established between clients.
IX. Active side and passive side
The two sides of a session must be either an active side or a passive side. A session
can have only one active side and one passive side. For a session established between
a client and a server, the client operates as the active side and the server operates as
6-2
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
the passive side. If a session is established between two clients, the one that initiates
the session is the active side and the other is the passive side.
6.1.3 Implementation
To implement DVPN, DVPN access devices must have DVPN proprietary protocol
employed, through which the DVPN server holds information about all successfully
registered clients, and the clients hold information about all sessions they establish,
such as the private IP addresses of destination devices (the IP addresses of tunnel
interfaces), the public IP addresses of destination devices (the IP addresses of WAN
interfaces), the UDP port numbers of the destination devices (when employing UDP),
the identifiers of session state. Following is the descriptions of phases undergone when
implementing DVPN to transmit data.
I. Register
After a client is configured with proper interface properties and the server address and
its interfaces are up, the client negotiates with the DVPN server for algorithm, key,
authentication (optional), information registering, policy issuing, and so on.
Registers are carried out through maps established between the clients and the servers.
A map remains after the client registers and accesses the DVPN domain. It is removed
only when the client exits the DVPN domain. If you remove a map through which a
client registers, the client releases all resources it occupies (including all sessions it
establishes) and resumes the initial state.
Figure 6-1 demonstrates the registering workflow. Any error during the workflow results
in the registering being aborted and cause the client resume the initial state.
Client
(1 )
Server
(2)
(3 )
( 4)
( 5)
(6)
( 7)
(8)
Figure 6-1 DVPN registering workflow
1)
The client sends algorithm negotiation request messages to the server.
2)
The server sends algorithm negotiation response messages to the client.
6-3
Operation Manual – VPN
H3C SecPath Series Security Products
3)
Chapter 6 DVPN Configuration
The client sends key negotiation request messages and server authentication
request messages to the server.
4)
The server sends key negotiation response messages, client authentication
messages, and server authentication response messages to the client.
5)
The client sends authentication messages to the server.
6)
The server sends authentication result to the client.
7)
The client sends register request messages to the server, where all information
about the client is included.
8)
The server sends register response messages to the client, where information
such as data encrypting policies, key, and the ID of the DVPN domain is included.
II. Establishing session
Immediately after a successful registration, the client establishes a session with the
DVPN server to transmit packets using DVPN. If the packets the server receives are
destined for other networks instead of the local private network, the server forwards the
packets and sends next hop redirecting messages to the source client to inform it of the
information about the destination. The client then sends session Setup requests to the
peer client to negotiate with it for establishing a separate session and the IPsec SA
(security association). After the session is established, the two clients can
communicate with each other without the server.
When removing a session, the server checks to see if it is coupled with a registered
map. If the map does not exist, the session is removed directly. Otherwise, you need to
remove the coupled map first.
III. Transmitting data
You can transmit data between entities (clients and servers) after the sessions between
them are established. The data being transmitted is encrypted using IPsec, with DES
as the encryption algorithm and MD5 as the authentication algorithm.
The encryption method mentioned above is employed by default and need not manual
configuration.
6.1.4 Basic Network Structure
DVPN adopts a client/server model. Among all the access devices in a DVPN domain,
only one can be the server and uses a fixed public IP address, whereas others operate
as clients. You need to configure information about the server manually on each client
to enable the clients to register with the server. A session is automatically established
between a client and the server after the client successfully registers with the server. By
sending redirecting packets, the server can provide information about other clients to a
client to enable sessions being established between clients, through which the DVPN
domain can be fully connected.
6-4
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
When transmitted in a DVPN domain, DVPN packets are encapsulated using UDP, that
is, DVPN control packets and other DVPN packets to be forwarded are encapsulated
using UDP. As UDP packets are capable of traversing NAT gateways, sessions can be
established between DVPN clients even though they use private IP addresses.
Server
Session
Session
Internet
Client
Session
Client
Figure 6-2 A simple DVPN network diagram
6.1.5 Traditional VPN versus DVPN
I. Drawbacks of traditional VPN
Current network solutions commonly use GRE (generic routing encapsulation) or
MPLS/BGP (multiprotocol label switching/border gateway protocol) to form Layer 3
VPNs. Both of these two kinds of VPNs suffer from the following drawbacks:
z
Complicated in networking and configuration. Layer 3 VPNs communicate through
point-to-point tunnels. So, to form a fully connected VPN with number of access
points of N, the number of point-to-point VPN tunnels to be manually configured is
N * (N-1) / 2.
z
Inconvenient in maintenance and expansion. For an established VPN, you must
reconfigure all other nodes if you add a node to the VPN or reconfigure an existing
node in the VPN, which results in high maintaining cost.
z
Unable to traverse NAT gateways. For VPN tunnels that are established using
GRE and with NAPT (network address port translation) gateways deployed at the
egresses, you must map each private IP address to a unique public IP address to
transmit packets along the VPN tunnel. So large amount of public IP addresses
are needed for this kind of VPNs. So GRE is not applicable in NAT gateways.
(VPNs that are established using early versions of IPsec cannot traverse NAT
gateways either. This problem is resolved by encapsulating IPsec packets as UDP
packets.)
z
Not applicable for dynamic IP addresses. VPN tunnels that are established using
GRE are based on fixed IP addresses. So you cannot establish VPNs for dial-up
subscribers using GRE.
6-5
Operation Manual – VPN
H3C SecPath Series Security Products
z
Chapter 6 DVPN Configuration
Not secure. L2TP (Layer 2 tunnel protocol) and GRE do not encrypt packets.
Whereas IPsec provides satisfactory security for packets forwarded across IPsec
VPNs.
z
IPsec does not support dynamical routes. VPN tunnels that are established using
GRE and L2TP are interface-based, whereas those that are established using
IPsec are data stream-oriented, so route learning is not applicable between these
two kinds of private networks interconnected with IPsec VPN tunnels, which is
contradictory to network dynamically planning.
II. Advantages of DVPN
DVPN has all advantages that traditional VPN benefits from. It also overcomes lot of
problems that traditional VPN faces. It provides an easy way to configure and plan
networks and is more powerful. It is more suitable for modern and future networks. It
features the following:
z
Ease of configuration. Instead of configuring logic interfaces as the tunnel ends for
each tunnel, only one logic tunnel interface is needed for a DVPN access device to
establish sessions with multiple other DVPN access devices, which simplifies
DVPN configuration remarkably and improves maintainability and extensibility. To
add a private network to an existing DVPN domain, you need only to configure
information about the DVPN server of the DVPN domain on the DVPN access
device of the private network.
z
Capable of NAT traversal. UDP-encapsulated DVPN packets are capable of
traversing NAT gateways. This enables VPN connections to be established
between internal network DVPN access devices and public network DVPN access
devices and enables VPNs that contain both internal private networks and
external private networks to be established.
z
Capable of establishing dynamic IP address-based VPN. You need only to provide
the IP address of the DVPN server to establish a tunnel in a DVPN domain. So
DVPN is applicable to subscribers that use dynamic IP addresses, such as dial-up
and xDSL.
z
Capable of establishing tunnels automatically. A DVPN server maintains
information about all DVPN access devices in the DVPN domain. The redirecting
function enables the DVPN clients acquire information about any other DVPN
clients in the DVPN domain from the DVPN server to establish sessions. A DVPN
client is only needed to be configured with information about itself and the DVPN
server, so the work load of network administration can be remarkably eased.
z
Encrypted registration. When registering with a DVPN server, a client first
negotiates with the server for the algorithm suite and keys, and then encrypts the
key registering information (such as user name and password) using the
negotiated algorithm. They can also validate the registering packets to secure the
key registering information.
6-6
Operation Manual – VPN
H3C SecPath Series Security Products
z
Chapter 6 DVPN Configuration
Authentication. When registering with a DVPN server, a client can authenticate the
server using a pre-shared-key to make sure the DVPN server is valid. The DVPN
server, in turn, can identify the clients that want to access the DVPN domain using
AAA to ensure DVPN clients are authenticated.
z
Centralized policy management. Policies applied to sessions in a DVPN domain
are the same. A DVPN server issues the policy of the DVPN domain to each
registered client, including the algorithm suite used in session negotiations, the
keepalive time of sessions, the idle timeout time of sessions, the IPsec encryption
algorithm, the renegotiation time of IPsec SA, and so on.
z
Encryption during session negotiation. In the course of session negotiation, all the
control packets are IPsec-encrypted using the algorithm suite the DVPN server
issues. The client negotiates with the DVPN server for the IPsec SA of the session
using the encryption and authentication algorithm issued by the DVPN server. DH
(Diffie-Hellman) is used for negotiating the key of the IPsec SA. Data that are to be
encrypted and transmitted through this session are encrypted using the IPsec SA
negotiated in the course of the session establishment and then are transmitted
through the DVPN domain. The IPsec SA of a session can be renegotiated. You
can specify an IPsec SA renegotiation interval to improve security.
z
Support for multiple DVPN domains. A single DVPN device can accommodate
multiple DVPN domains. That is, a firewall can belong to both DVPN domain A and
DVPN domain B simultaneously, and a DVPN device can be a client in DVPN
domain A and the DVPN server in DVPN domain B at same time. A DVPN device
can accommodate up to 200 DVPN domains and can be the DVPN server of up to
200 DVPN domains. This improves network flexibility remarkably and protects
user investment efficiently, and enables you to make full use of network device
resource. When multiple DVPN domains are configured on one DVPN device, you
can isolate these DVPN domains using private network routes.
z
Support for dynamic routes. In a DVPN domain, route packets that need to be
transmitted through tunnel interfaces can be broadcast over all sessions to enable
route learning in DVPN domains. When accompanied with dynamic routing
protocols, DVPN can simplify planning of private networks that are to access a
DVPN domain and the configuration of the entire network, improve network
maintainability and automation.
6.2 DVPN Configuration
DVPN configuration comprises client configuration and server configuration.
I. Client configuration
As for DVPN clients, you need to perform basic configuration, tunnel interface
configuration, and DVPN class configuration.
1)
Basic configuration
6-7
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
Basic configuration includes the following:
z
Enable/Disable DVPN
z
Configure the client registration interval
z
Configure the registering retries
z
Configure the dumb time
2)
Tunnel interface configuration
Tunnel interface configuration includes the following:
z
Encapsulate the tunnel interface using UDP DVPN
z
Configure the tunnel interface to client type
z
Configure the source address or source interface of the tunnel interface
z
Configure the DVPN class to be applied to the tunnel interface
z
Configure the DVPN domain the tunnel interface belongs to
z
Configure register type (optional)
z
Configure IPsec-encrypted data stream
3)
DVPN class configuration
DVPN class configuration refers to configuring parameters that are necessary for a
client to register with a DVPN server and providing information used in negotiation in a
DVPN class view, it mainly includes the following:
z
Create a DVPN class and enter its view
z
Assign a public IP address to the DVPN server
z
Assign a private IP address to the DVPN server (optional)
z
Configure the register algorithm suite (optional. The default registering algorithm
suite is DES-MD5-DH1.)
z
Specify how the client authenticates the DVPN server (optional)
z
Configure the pre-shared-key used when the client authenticates the DVPN server
(optional)
z
Configure user information used when the client registers with the DVPN server
(optional)
II. DVPN server configuration
As for a DVPN server, you need to perform basic configuration, tunnel interface
configuration, and DVPN policy suite configuration (DVPN policies are configured in
DVPN policy views), which are described as follows.
1)
Basic configuration
Basic configuration includes the following:
z
Enable/Disable DVPN
z
Configure the map aging time
z
Configure how to authenticate the clients
z
Configure the pre-shared-key
2)
Tunnel interface configuration
6-8
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
Tunnel interface configuration includes the following:
z
Encapsulate the tunnel interface with UDP DVPN
z
Configure the tunnel interface to server
z
Configure the DVPN domain the tunnel interface belongs to
z
Configure the source address or source interface of the tunnel interface
z
Configure the DVPN policy the tunnel interface uses (optional)
z
Configure IPsec-encrypted data stream
3)
DVPN policy suite configuration
DVPN policy suite configuration includes the following:
z
Create and enter a DVPN policy view
z
Configure how the DVPN server authenticates the clients (optional and is NONE
by default)
z
Configure the algorithm suite for a specified session (optional and is des-md5-dh1
by default)
z
Configure the timeout time for a specified session (optional and is 300 seconds by
default)
z
Configure the interval for sending keepalive packets (optional and is 10 seconds
by default)
z
Configure the interval for sending requests to establish a session (optional and is
10 seconds by default)
z
Configure the IPsec algorithm suite (optional and is des-md5-dh1 by default)
z
Configure the time out time to renegotiate a specified IPsec SA (optional and is
3600 seconds by default)
To correspond to the configurations mentioned above, following sections describe how
to configure DVPN in terms of basic configuration, tunnel interface configuration, DVPN
class configuration, and DVPN policy configuration.
6.2.1 Basic DVPN Configuration
I. Enabling/Disabling DVPN
Perform these operations to enable/disable DVPN. If you disable DVPN on a DVPN
server, the existing DVPN sessions are removed after they time out.
Perform the following configuration in system view on a client or a DVPN server.
Table 6-1 Enable/Disable DVPN
Operation
Command
Enable DVPN
dvpn service enable
Disable DVPN
undo dvpn service enable
DVPN is disabled by default.
6-9
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
II. Configuring the pre-shared-key
Perform
these
operations
to
configure/remove
authentication
information
(pre-shared-key) on a DVPN server. If a client authenticates using a pre-shared-key, it
specifies the pre-shared-key the DVPN server to be accessed uses. The specified
pre-shared-key must be identical to the one the DVPN server owns.
Perform the following configuration in system view on a DVPN server.
Table 6-2 Configure the pre-shared-key for a DVPN server
Operation
Command
Configure a pre-shared-key
dvpn server pre-shared-key key
Remove a pre-shared-key
undo dvpn server pre-shared-key
Pre-shared-keys are not configured by default.
III. Configuring how to authenticate a client
At present, PAP (password authentication protocol) and CHAP (challenge
authentication protocol) are available for a DVPN server to authenticate a clients that
attempt to access the DVPN domain. After you perform this operation to specify how a
DVPN server authenticates a client, a DVPN server authenticates clients in the
specified way if it has no DVPN policy applied.
Perform the following configuration in system view on a DVPN server.
Table 6-3 Configure how to authenticate a client
Operation
Command
Configure how to authenticate a client
dvpn server authentication-client
method { none | { chap | pap }
[ domain isp-name ] }
A DVPN server does not authenticate clients by default.
IV. Configuring the map age time
You can limit the number of maps by configuring the map age time. For clients that
cannot successfully register with the DVPN server, the related maps are removed when
the map age time expires.
Perform the following configuration in system view.
Table 6-4 Configure the map age time
Operation
Command
Configure the map age time
dvpn server map age-time time
6-10
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
Operation
Command
Revert the map age time to the default
undo dvpn server map age-time
The default map age time is 30 seconds.
V. Configuring the registering interval for a client
If a client fails to register with a DVPN server, it registers with the DVPN server again
after a specified interval. You can configure the register interval on a client.
Perform the following configuration in system view on a client.
Table 6-5 Configure the registering interval for a client
Operation
Command
Configure the register interval for the
client
dvpn client register-interval
time-interval
Revert to the default register interval for
the client
undo dvpn client register-interval
The default register interval is 10 seconds.
VI. Configuring the register retries for a client
A client turns to dumb state if it fails to register with a DVPN server for specified times.
You can configure the maximum retries during a register round by performing this
operation.
Perform the following configuration in system view on a client.
Table 6-6 Configure the registering retries for a client
Operation
Command
Configure the register retries for the client
dvpn client register-retry times
Revert to the default register retries for the
client
undo dvpn client register-retry
The default register retries for the client is 3.
Caution:
A client in dumb state does not register with a DVPN server.
6-11
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
VII. Configuring the dumb time for a client
When registering with the DVPN server, a client can try for a specified number of times.
If all attempts fail, the client turns into the dumb state. A client in the dumb state cannot
register with the DVPN server. After a specified interval called dump interval elapses,
the client becomes active and can register with the DVPN server again.
Perform the following configuration in system view on a client.
Table 6-7 Configure the dumb time for a client
Operation
Command
Configure the dumb time for the client
dvpn client register-dumb time
Revert to the default dumb time for the client
undo dvpn client register-dumb
The default dumb time for the client is 300 seconds.
6.2.2 Configuring the Tunnel Interface
I. Configuring the encapsulation format
Before configuring other DVPN parameters, be sure to encapsulate the tunnel interface
with UDP DVPN.
Perform the following configuration in tunnel interface view on a client or a DVPN
server.
Table 6-8 Configure the encapsulation format
Operation
Command
Encapsulate the tunnel interface with
UDP DVPN
tunnel-protocol udp dvpn
A tunnel interface is encapsulated using GRE by default.
II. Configuring the type of the tunnel interface
Configure the tunnel interface as server or client type according to its location (server
side or client side).
Perform the following configuration in tunnel interface view on a client or a DVPN
server.
6-12
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
Table 6-9 Configure the type of the tunnel interface
Operation
Command
Configure the type of the tunnel interface
dvpn interface-type { client | server }
Restore the default type of the tunnel
interface
undo dvpn interface-type
A tunnel interface is of client type by default.
III. Configuring register type for a DVPN client
You can only use the dvpn register-type command on the client. When registering
with the server, the client can ask the server to the data packet from this client and
notify the server not to send the registering information about this client to other clients.
Perform the following configuration in tunnel interface view on the client.
Table 6-10 Configure register type for a DVPN client
Operation
Command
Configure register type for the DVPN
client
dvpn register-type { forward |
undistributed } *
Remove the configuration
undo dvpn register-type { forward |
undistributed } *
By default, the register type for the DVPN client is not configured.
IV. Configuring the DVPN domain the tunnel interface belongs to
You can configure the ID of the DVPN domain the tunnel interface belongs to by
performing this operation. (Tunnel interfaces that belong to the same DVPN domain
have the same DVPN ID.)
Perform the following configuration in tunnel interface view on a client or a DVPN
server.
Table 6-11 Configure the DVPN domain the tunnel interface belongs to
Operation
Command
Configure the DVPN domain the tunnel
interface belongs to
dvpn dvpn-id dvpn-id
Revert the tunnel interface to the default
undo dvpn dvpn-id
A tunnel interface is not configured with a DVPN ID.
6-13
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
V. Configuring the source end address of the tunnel interface
The source address or source interface refers to address of the interface DVPN
packets sourced from. The source end address along with the destination address,
which must be configured on both the server end and the client end respectively,
uniquely identify a tunnel. The two addresses are source and destination addresses
mutually.
Perform the following configuration in tunnel interface view on a client or a DVPN
server.
Table 6-12 Configure the source end address of the tunnel interface
Operation
Command
Configure the source end address or
source interface of the tunnel interface
source { X.X.X.X | interface-type
interface-num }
Remove the source end address or the
source interface of the tunnel interface
undo source
VI. Configuring the DVPN class to be applied to the tunnel interface (client
side only)
After configuring the DVPN server in a DVPN class view on the client side, perform the
following operations to apply the DVPN class.
Perform the following configuration in tunnel interface view on the client side.
Table 6-13 Configure/Remove the DVPN class to be applied to the tunnel interface
Operation
Command
Configure the DVPN class to be applied
to the tunnel interface
dvpn server dvpn-class-name
Remove the DVPN class applied to the
tunnel interface
undo dvpn server dvpn-class-name
A tunnel interface does not have a DVPN class applied by default.
VII. Configuring the DVPN policy to be applied to the tunnel interface (server
side only)
After configuring the policy in a DVPN policy view on the server side, perform the
following operations to apply it to the DVPN domain.
Perform the following configuration in tunnel interface view on the server side.
6-14
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
Table 6-14 Configure/Remove the DVPN policy to be applied to the tunnel interface
Operation
Command
Configure the DVPN policy to be applied
to the tunnel interface
dvpn policy dvpn-policy-name
Remove the DVPN policy applied to the
tunnel interface
undo dvpn policy dvpn-policy-name
A tunnel interface does not have a DVPN policy applied by default.
VIII. Configuring IPsec-encrypted data stream
Use the dvpn security acl command in conjunction with the acl and rule commands.
When the ACL referenced in the dvpn security acl command contains a set of deny
rules, matched packets are not to be encrypted. Note that configuring permit rules is
meaningless for the dvpn security acl command.
Perform the following configuration in tunnel interface view.
Table 6-15 Configure IPsec-encrypted data stream
Operation
Command
Configure an ACL to specify packets that
are not IPsec-encrypted
dvpn security acl acl-number
Remove all configured ACLs
undo dvpn security acl
All packets that pass through the tunnel interface are IPsec-encrypted by default.
6.2.3 Configuring a DVPN class
After configuring parameters of a specified DVPN server used for clients to register with
the DVPN server in a DVPN class view (such as private IP address, public IP address,
and user name), you need to perform corresponding configuration on the client side, as
described in the following sections.
I. Creating a DVPN class and enter its view
You can create a DVPN class and enter its view, or remove an existing DVPN class by
performing the following operations. A DVPN class that is in use cannot be removed.
Perform the following configuration in system view.
6-15
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
Table 6-16 Create/Remove a DVPN class
Operation
Command
Create and enter a DVPN class
dvpn class dvpn-class-name
Remove a DVPN class view
undo dvpn class dvpn-class-name
No DVPN class is configured by default.
II. Assigning a public IP address to a DVPN server
The IP address here refers to the fixed public IP address assigned to the DVPN server.
Perform the following configuration in DVPN class view.
Table 6-17 Assign a public IP address to the DVPN server
Operation
Command
Assign a public IP address to the DVPN server
public-ip ip-address
Remove a public IP address
undo public-ip
A DVPN server is not assigned a public IP address by default.
III. Assigning a private IP address to a DVPN server
The IP address here refers to the IP address of the tunnel interface through which the
DVPN server accesses a DVPN domain and is optional. When a client configured with
the private IP address of the DVPN server registers, the response information contains
the private IP address of the DVPN server. And the client tears down the connection if
the two private IP address are not the same.
Perform the following configuration in DVPN class view.
Table 6-18 Assign a private IP address to a DVPN server
Operation
Command
Assign a private IP address to a DVPN server
private-ip ip-address
Remove the private IP address
undo private-ip
A DVPN server is not assigned a private IP address by default.
IV. Configuring the register algorithm suite
DVPN register control packets must be encrypted for security. The encryption algorithm,
authentication algorithm, and key negotiation algorithm are determined by the register
algorithm suite.
Perform the following configuration in DVPN class view.
6-16
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
Table 6-19 Configure the register algorithm suite
Operation
Command
Configure the register algorithm suite
algorithm-suite suite-number
Revert to the default register algorithm suite
undo algorithm-suite
The suite-number parameter is 1 by default, which stands for DES-MD5-GROUP1.
Refer to Command Manual for the meanings of other values.
V. Specifying how the client authenticates the DVPN server
A client can authenticate the DVPN server to be accessed using a pre-shared-key. The
configured pre-shared-key must be identical to the one the DVPN server holds for the
client to successfully register with the DVPN server.
Perform the following configuration in DVPN class view.
Table 6-20 Specify how the client authenticates the DVPN server
Operation
Command
Specify to authenticate the DVPN server
using the pre-shared-key
authentication-server method
pre-share
Specify not to authenticate the DVPN
server
authentication-server method none
A client does not authenticate a DVPN server by default.
Table 6-21 Configure a pre-shared-key for a DVPN server
Operation
Command
Configure a pre-shared-key for a DVPN server
pre-shared-key key
Remove the configured pre-shared-key
undo pre-shared-key
A DVPN server is not configured with a pre-shared-key by default.
VI. Configuring the user name and password for a client
User names and passwords are used when clients register with DVPN servers. You
must configure the user name and password in a DVPN class view for a client if it is to
register with a DVPN server that authenticates registering clients.
Perform the following configuration in DVPN class view.
6-17
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
Table 6-22 Configure the user name and password for a client
Operation
Command
Configure the user name and password for a
client
local-user username password
{ simple | cipher } password
Remove the user name and password of a client
undo local-user
A client is not configured with a user name and password by default.
6.2.4 Configuring a DVPN policy
Parameters about DVPN policy, such as session algorithm, IPsec algorithm for data,
time parameters, are configured in DVPN policy views. A DVPN server issues DVPN
policies applied in the DVPN domain to clients that successfully register with it.
Caution:
After modifying and applying a policy on a tunnel interface, you must reboot the
interface or use the shutdown and undo shutdown commands on the interface to
validate the new policy.
I. Creating a DVPN policy view
You can create and enter a DVPN policy view, or remove an existing DVPN policy by
performing the following operations. To remove a DVPN policy that is applied in a
DVPN domain, you must disable it first.
Perform the following configuration in system view.
Table 6-23 Create a DVPN policy view
Operation
Command
Create a DVPN policy view and enter its
view
dvpn policy dvpn-policy-name
Remove a DVPN policy
undo dvpn policy dvpn-policy-name
No DVPN policy is configured by default.
II. Configuring how a DVPN server authenticates clients
You can configure a DVPN server to authenticate clients that are to access the DVPN
domain. At present, you can specify to authenticate using PAP and CHAP.
6-18
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
Perform the following configuration in DVPN policy view.
Table 6-24 Configure how a DVPN server authenticates clients
Operation
Command
Configure how a DVPN server
authenticates clients
authentication-client method { none |
{ chap | pap } [ domain isp-name ] }
A DVPN server does not authenticate clients by default.
III. Configuring the encryption algorithm suite for a session
You can apply DES, 3DES, and AES encryption algorithms, MD5 and SHA1
authentication algorithms, and DH-group1 and DH-group2 key negotiation algorithms
to control packets transmitted during DVPN session negotiation by performing the
following operations.
Perform the following configuration in DVPN policy view.
Table 6-25 Configure the encryption algorithm suite for a session
Operation
Command
Configure the encryption algorithm suite
for a session
session algorithm-suite suite-number
Revert to the default encryption
algorithm suite
undo session algorithm-suite
The suite-number parameter is 1 by default, which stands for DES (for encryption),
MD5 (for authentication) and DH-group1 (for key negotiation).
IV. Configuring the idle time out time for a session
A session is torn down if no packet passes through it during a specified interval known
as the idle time out time.
Perform the following configuration in DVPN policy view.
Table 6-26 Configure the idle time out time for a session
Operation
Command
Configure the idle time out time for a session
session idle-time time-interval
Revert to the default idle time out time
undo session idle-time
The default idle time out time is 300 seconds.
6-19
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
V. Configuring the interval for sending keepalive packets
After a session is established, the active side sends keepalive packets regularly to
check the connection state of the session if no packet passes through the session. The
keepalive packet is not sent when there is any packet passes through the session.
Perform the following configuration in DVPN policy view.
Table 6-27 Configure the interval for sending keepalive packets
Operation
Command
Configure the interval for sending
keepalive packets
session keepalive-interval
time-interval
Revert to the default interval for sending
keepalive packets
undo session keepalive-interval
The default interval for sending keepalive packets is 10 seconds.
VI. Configuring the interval for sending requests to establish a session
If a session is not successfully established, the initiator sends a request again to try to
establish the session after a specific interval. The initiator fails to establish a session if
the session is not established after the initiator sends three successive requests.
Perform the following configuration in DVPN policy view.
Table 6-28 Configure the interval for sending requests to establish a session
Operation
Command
Configure the interval for sending
requests to establish a session
session setup-interval time-interval
Revert to the default interval for sending
requests to establish a session
undo session setup-interval
The default interval for sending requests to establish a session is 10 seconds.
VII. Configuring the IPsec algorithm suite
Packets transmitted in a DVPN domain are IPsec-encrypted for security. At present,
DES, 3DES, and AES encryption algorithms and MD5, SHA1 authentication algorithms
are available. You can specify the algorithm suite used when an IPsec SA forwards
packets by performing the following operations.
Perform the following configuration in DVPN policy view.
6-20
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
Table 6-29 Configure the IPsec algorithm suite
Operation
Command
Configure the IPsec algorithm suite
data algorithm-suite suite-number
Revert to the default IPsec algorithm suite
undo data algorithm-suite
The suite-number parameter is 1 by default, which stands for DES (for encryption) and
MD5 (for authentication).
VIII. Configuring the Lifetime of IPsec SA
Perform the following configuration in DVPN policy view.
Table 6-30 Configure the lifetime of IPsec SA
Operation
Command
Configure the lifetime of IPsec SA
data ipsec-sa duration time-based
time-interval
Revert to the default lifetime of IPsec SA
undo data ipsec-sa duration
time-based
The default lifetime of IPsec SA is 3600 seconds.
6.2.5 Displaying and Debugging DVPN
Execute the display command in any view to display how DVPN operates.
Execute the reset command in user view to clear sessions, maps, statistics information,
or initiate a DVPN domain.
Execute the debugging command in user view to debug DVPN.
Table 6-31 Display and debug DVPN
Operation
Command
Enable/Disable debugging for DVPN
[undo] debugging dvpn { all | error |
event { all | register | session | misc } |
hexadecimal | packet { all | control |
data | ipsec } }
Display global information about DVPN
in a system or information about a DVPN
domain
display dvpn info { dvpn-id dvpn-id |
global }
Display information about maps in a
DVPN domain
display dvpn map {all | dvpn-id
dvpn-id | public-ip public-ip }
Display information about sessions in a
DVPN domain
display dvpn session { all | dvpn-id
dvpn-id [ private-ip private-ip ] }
6-21
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
Operation
Command
Display information about IPsec SAs in a
DVPN domain
display dvpn ipsec-sa { all | dvpn-id
dvpn-id [ private-ip private-ip ] }
Display information about online DVPN
users
display dvpn online-user
Initiate a DVPN domain
reset dvpn all dvpn-id
Clear a specified map
reset dvpn map public-ip port
[ client-id ]
Clear a specified session
reset dvpn session dvpn-id private-ip
Clear DVPN statistics information
reset dvpn statistics
Note:
If you want to use a new policy after changing the dvpn policy, you must reboot the
firewall or shutdown/undo shutdown the tunnel interface. The new policy cannot be
used by using the reset command.
6.3 DVPN Implementation
6.3.1 NAT traversal
I. Network requirements
As Figure 6-3 shows, Branch A and Branch B establish DVPN connections with the
headquarters respectively. The private network of Branch A is connected to the private
network of the headquarters through NAT (network address translation), so DVPN NAT
traversal is needed for this implementation. Detailed requirements are as follows:
z
Use the default algorithm suite (algorithm suite 1) for register and sessions, that is,
use DES for encryption, MD5 for authentication, and DH-group1 for key
negotiation.
z
Data is IPsec-encrypted for security using algorithm suite 1. That is, use DES for
encryption, MD5 for authentication, and DH-group1 for key negotiation.
6-22
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
II. Network diagram
Server
Ethernet0/0/1:10. 0. 1.1/24
Headquarters
Tunnel0 : 10.0. 0.1/24
Ethernet0/0 /0: 201. 1. 1. 1
Internet
Ethernet0/0/0: 201.1.1.2/24
Ethernet0/0/0: 201.1.1.3
Tunnel0: 10.0.0.3/24
Client2
NAT
Ethernet0/0/1:192.168.1.1/24
T unnel0:10.0.0.2/24
Ethernet0/0/1:10.0.3.1/24
Ethernet0/0/0:192.168.1.2/24
Client1
Ethernet0/0/1:10.0.2.1/24
Branch B
Branch A
Figure 6-3 Network diagram for NAT traversal
III. Configuration procedure
1)
Configure Server as follows:
# Configure Ethernet0/0/0 interface.
[Server] interface Ethernet0/0/0
[Server-Ethernet0/0/0] ip address 201.1.1.1 255.255.255.0
[Server-Ethernet0/0/0] quit
# Configure Ethernet0/0/1 interface.
[Server] interface Ethernet0/0/1
[Server-Ethernet0/0/1] ip address 10.0.1.1 255.255.255.0
[Server-Ethernet0/0/1] quit
# Configure DVPN policy, with all the settings using the default value.
[Server] dvpn policy testpolicy
[Server-Policy-testpolicy] quit
# Configure Tunnel0 interface.
[Server] interface tunnel 0
[Server-Tunnel0] tunnel-protocol udp dvpn
6-23
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
[Server-Tunnel0] dvpn interface-type server
[Server-Tunnel0] ip address 10.0.0.1 255.255.255.0
[Server-Tunnel0] source Ethernet0/0/0
[Server-Tunnel0] dvpn dvpn-id 1
[Server-Tunnel0] dvpn policy testpolicy
[Server-Tunnel0] quit
# Configure static routes.
[Server] ip route-static 10.0.2.0 255.255.255.0 10.0.0.2
[Server] ip route-static 10.1.3.0 255.255.255.0 10.0.0.3
2)
Configure the NAT device as follows:
# Configure Ethernet0/0/0 interface.
[Nat] interface Ethernet0/0/0
[Nat-Ethernet0/0/0] ip address 201.1.1.2 255.255.255.0
[Nat-Ethernet0/0/0] nat outbound 3000
[Nat-Ethernet0/0/0] quit
# Configure Ethernet0/0/1 interface.
[Nat] interface Ethernet0/0/1
[Nat-Ethernet0/0/1] ip address 192.168.1.1 255.255.255.0
[Nat-Ethernet0/0/1] quit
# Configure an ACL.
[Nat] acl number 3000
[Nat-Acl-Adv-3000] rule permit ip
# Configure a static route.
[Nat] ip route-static 10.0.2.0 255.255.255.0 192.168.1.2
3)
Configure Client 1 as follows:
# Configure Ethernet0/0/0 interface.
[Client1] interface Ethernet0/0/0
[Client1-Ethernet0/0/0] ip address 192.168.1.2 255.255.255.0
[Client1-Ethernet0/0/0] quit
# Configure Ethernet0/0/1 interface.
[Client1] interface Ethernet0/0/1
[Client1-Ethernet0/0/1] ip address 10.0.2.1 255.255.255.0
[Client1-Ethernet0/0/1] quit
# Configure the DVPN class.
[Client1] dvpn class testserver
[Client1-dvpn-class-testserver] public-ip 201.1.1.1
[Client1-dvpn-class-testserver] quit
# Configure Tunnel 0 interface.
6-24
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
[Client1] interface tunnel 0
[Client1-Tunnel0] ip address 10.0.0.2 255.255.255.0
[Client1-Tunnel0] tunnel-protocol udp dvpn
[Client1-Tunnel0] source Ethernet0/0/0
[Client1-Tunnel0] dvpn interface-type client
[Client1-Tunnel0] dvpn server testserver
[Client1-Tunnel0] dvpn dvpn-id 1
[Client1-Tunnel0] quit
# Configure static routes.
[Client1] ip route-static 10.0.1.0 255.255.255.0 10.0.0.1
[Client1] ip route-static 10.1.3.0 255.255.255.0 10.0.0.3
[Client1] ip route-static 201.1.1.0 255.255.255.0 192.168.1.1
4)
Configure Client 2 as follows:
# Configure Ethernet0/0/0 interface.
[Client2] interface Ethernet0/0/0
[Client2-Ethernet0/0/0] ip address 201.1.1.3 255.255.255.0
[Client2-Ethernet0/0/0] quit
# Configure Ethernet0/0/1 interface.
[Client2] interface Ethernet0/0/1
[Client2-Ethernet0/0/1] ip address 10.1.3.1 255.255.255.0
[Client2-Ethernet0/0/1] quit
# Configure the DVPN class.
[Client2] dvpn class testserver
[Client2-dvpn-class-testserver] public-ip 201.1.1.1
[Client2-dvpn-class-testserver] quit
# Configure Tunnel 0 interface.
[Client2] interface tunnel 0
[Client2-Tunnel0] ip address 10.0.0.3 255.255.255.0
[Client2-Tunnel0] tunnel-protocol udp dvpn
[Client2-Tunnel0] source Ethernet0/0/0
[Client2-Tunnel0] dvpn interface-type client
[Client2-Tunnel0] dvpn server testserver
[Client2-Tunnel0] dvpn dvpn-id 1
[Client2-Tunnel0] quit
# Configure static routes.
[Client2] ip route-static 10.0.1.0 255.255.255.0 10.0.0.1
[Client2] ip route-static 10.0.2.0 255.255.255.0 10.0.0.2
6-25
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
6.3.2 GRE Cooperation
I. Network requirements
As Figure 6-4 shows, the headquarters, Branch A and Branch B form a VPN. This VPN
comprises a DVPN established between the headquarters and Branch A and a VPN
established between the headquarters and Branch B using GRE.
Configure to have Server and Client 1 authenticate to each other when Client 1
attempts to access the DVPN.
II. Network diagram
Server
Headquarters
Ethernet0/0/1:10. 0. 1.1/24
Tunnel1:10. 1. 0.1/24
Tunnel0 : 10.0. 0.1/24
Ethernet0/0 /0: 201. 1. 1. 1
GRE
DVPN
Internet
Ethernet0/0/0: 201.1.1.2/24
Ethernet0/0/0: 201.1.1.3
Tunnel1:1 0.1.0.2/24
Tunnel0:10.0.0.2/24
Client1
Client2
Ethernet0/0/1:10.0.2.1/24
Ethernet0/0/1:10.1.2.1/24
Branch A
Branch B
Figure 6-4 Network diagram for GRE cooperation
III. Configuration procedure
1)
Configure Server as follows:
# Configure Ethernet0/0/0 interface.
[Server] interface Ethernet0/0/0
[Server-Ethernet0/0/0] ip address 201.1.1.1 255.255.255.0
[Server-Ethernet0/0/0] quit
# Configure Ethernet0/0/1 interface.
[Server] interface Ethernet0/0/1
[Server-Ethernet0/0/1] ip address 10.0.1.1 255.255.255.0
[Server-Ethernet0/0/1] quit
# Configure a pre-shared-key.
6-26
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
[Server] dvpn server pre-shared-key 123456
# Configure to authenticate locally.
[Server] domain dvpn
[Server-isp-dvpn] scheme local
[Server-isp-dvpn] quit
# Configure a DVPN policy.
[Server] dvpn policy testpolicy
[Server-dvpn-Policy-testpolicy] authentication-client method chap domain
dvpn
[Server-dvpn-Policy-testpolicy] data algorithm-suite 7
[Server-dvpn-Policy-testpolicy] session algorithm-suite 12
[Server-dvpn-Policy-testpolicy] quit
# Configure a local DVPN user.
[Server] local-user dvpnuser
[Server-luser-dvpnuser] password simple dvpnuser
[Server-luser-dvpnuser] service-type dvpn
[Server-luser-dvpnuser] quit
# Configure Tunnel 0 interface used by DVPN.
[Server] interface tunnel 0
[Server-Tunnel0] tunnel-protocol udp dvpn
[Server-Tunnel0] dvpn interface-type server
[Server-Tunnel0] ip address 10.0.0.1 255.255.255.0
[Server-Tunnel0] source Ethernet0/0/0
[Server-Tunnel0] dvpn dvpn-id 1
[Server-Tunnel0] dvpn policy testpolicy
[Server-Tunnel0] quit
# Configure Tunnel 1 interface used by GRE.
[Server] interface tunnel 1
[Server-Tunnel1] ip address 10.1.0.1 255.255.255.0
[Server-Tunnel1] destination 201.1.1.3
[Server-Tunnel1] source Ethernet0/0/0
[Server-Tunnel1] quit
# Configure static routes.
[Server] ip route-static 10.1.2.0 255.255.255.0 tunnel1
[Server] ip route-static 10.0.2.0 255.255.255.0 10.0.0.2
2)
Configure Client 1 as follows:
# Configure Ethernet0/0/0 interface.
[Client1] interface Ethernet0/0/0
[Client1-Ethernet0/0/0] ip address 201.1.1.2 255.255.255.0
6-27
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
[Client1-Ethernet0/0/0] quit
# Configure Ethernet 0/0/1 interface.
[Client1] interface Ethernet0/0/1
[Client1-Ethernet0/0/1] ip address 10.0.2.1 255.255.255.0
[Client1-Ethernet0/0/1] quit
# Configure the DVPN class.
[Client1] dvpn class testserver
[Client1-dvpn-class-testserver] public-ip 201.1.1.1
[Client1-dvpn-class-testserver] authentication-server method pre-share
[Client1-dvpn-class-testserver] pre-shared-key 123456
[Client1-dvpn-class-testserver] local-user dvpnuser@dvpn password simple
dvpnuser
[Client1-dvpn-class-testserver] quit
# Configure Tunnel0 interface.
[Client1] interface tunnel 0
[Client1-Tunnel0] ip address 10.0.0.2 255.255.255.0
[Client1-Tunnel0] tunnel-protocol udp dvpn
[Client1-Tunnel0] source Ethernet0/0/0
[Client1-Tunnel0] dvpn interface-type client
[Client1-Tunnel0] dvpn server testserver
[Client1-Tunnel0] dvpn dvpn-id 1
[Client1-Tunnel0] quit
# Configure static routes.
[Client1] ip route-static 10.0.1.0 255.255.255.0 10.0.0.1
[Client1] ip route-static 10.1.2.0 255.255.255.0 10.0.0.1
3)
Configure Client 2.
# Configure Ethernet0/0/0 interface.
[Client2] interface Ethernet0/0/0
[Client2-Ethernet0/0/0] ip address 201.1.1.3 255.255.255.0
[Client2-Ethernet0/0/0] quit
# Configure Ethernet0/0/1 interface.
[Client2] interface Ethernet0/0/1
[Client2-Ethernet0/0/1] ip address 10.1.2.1 255.255.255.0
[Client2-Ethernet0/0/1] quit
# Configure Tunnel0 interface.
[Client2] interface tunnel 0
[Client2-Tunnel0] ip address 10.1.0.2 255.255.255.0
[Client2-Tunnel0] source Ethernet0/0/0
[Client2-Tunnel0] destination 201.1.1.1
6-28
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 6 DVPN Configuration
[Client2-Tunnel0] quit
# Configure static routes.
[Client2] ip route-static 10.0.1.0 255.255.255.0 10.1.0.1
[Client2] ip route-static 10.0.2.0 255.255.255.0 10.1.0.1
6-29
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Chapter 7 BGP/MPLS VPN Configuration
7.1 BGP/MPLS VPN Overview
Traditional VPN, for which layer 2 tunneling protocol (L2TP, L2F and PPTP, etc.) or
layer 3 tunnel technology (IPsec, GRE and etc.) is adopted, is a great success in such
aspects as solving network security and flexibility and is widely used. However, as the
connecting domain extends, the deficiency of traditional VPN on such aspects as
expansibility and manageability becomes more and more obvious. In addition, QoS
(Quality of Service) and security are also the difficult problem for traditional VPN.
MPLS (Multiprotocol Label Switching) technology is fit for VPN networking. With MPLS
network, the IP-based VPN service can be realized easily, thus the requirements for the
expansibility and manageability of VPN are satisfied. In addition, security precautions
can be adopted on MPLS VPN to ensure that no IP connection can be established
between different VPNs and thus VPN security is guaranteed. The VPN constructed by
using MPLS also provides the possibility for the implementation of value-added service.
Multiple VPNs can be formed from a single access point, and each VPN represents a
different service, making the network able to transmit services of different types in a
flexible way.
Comware provides comparatively complete BGP/MPLS VPN networking capabilities:
z
Address separation. Allow the address overlapping of the different VPN or
between VPN and public network.
z
Supporting MP-BGP advertising VPN routing message, establishing BGP/MPLS
VPN.
z
Forwarding VPN data stream over MPLS LSP.
z
Providing MPLS VPN performance monitoring and fault detecting tools.
7-1
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
7.1.1 BGP/MPLS VPN Model
I. BGP/MPLS VPN model
VPN1
site 1
site 1
Backbone network of
the service provider
P
P
PE
CE
CE
VPN 2
PE
CE
site 2
VPN2
site 3
P
P
PE
VPN1
site 2
CE
CE
Figure 7-1 MPLS VPN model
As shown in Figure 7-1, MPLS VPN model contains three parts: CE, PE and P.
z
CE (Customer Edge) device: It is a composing part of the customer network, which
is usually connected with the service provider directly via an interface. It is
commonly a router. CE cannot “sense” the existence of VPN.
z
PE (Provider Edge) router: It is the Provider Edge router, namely the edge device
of the provider network, which is connected with the customer’s CE directly. In
MPLS network, PE router disposes all the processing for VPN.
z
P (Provider) router: It is the backbone router in the provider network, which is not
connected with CE directly. P router needs to possess MPLS basic forwarding
capability.
The classification of CE and PE mainly depends on the range for the management of
the provider and the customer, and CE and PE are the edges of the management
domains. Firewalls can be used as the CE or PE devices.
II. Basic concepts in BGP/MPLS VPN
1)
vpn-instance
vpn-instance is an important concept in VPN routing in MPLS. In actual network, each
site on PE corresponds to a single vpn-instance (their association is implemented via
interface binding). If subscribers on one site belong to multiple VPNs, then the
corresponding vpn-instance should include information about all these VPNs.
Specifically, such information should be included in vpn-instance: label forwarding table,
IP routing table, the interfaces bound with vpn-instance, and the management
7-2
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
information (RD, route filtering policy, member interface list, etc). It includes the VPN
membership and routing rules of this site.
PE is responsible for updating and maintaining the correlation between vpn-instance
and VPN. To avoid data leakage from the VPN and illegal data entering into the VPN,
each vpn-instance on the PE has an independent set of routing table and label
forwarding table, in which the forwarding information of the message is saved
2)
MP-BGP
MP-BGP (multiprotocol extensions for BGP-4, see RFC2283) propagates VPN
membership information and routes between PE routers. It features backward
compatibility: It not only supports conventional IPv4 address family, but also supports
other address families, for example, VPN-IPv4 address family. MP-BGP ensures that
VPN private routes are only advertised within VPNs, as well as implementing
communication between MPLS VPN members.
3)
VPN-IPv4 address family
VPN is just a private network, so it can use the same IP address to indicate different
sites. But the IP address is supposed as unique when MP-BGP advertises CE routes
between PE routers, so routing errors may occur for the different meaning in two
systems. The solution is to switch IPv4 addresses to VPN-IPv4 address family to
generate a globally unique address before advertising them, so PE routers is required
to support MP-BGP.
A VPN-IPv4 address consists of 12 bytes, and the first eight bytes represent the RD
(Route Distinguisher), which are followed by a 4-byte IPv4 address. The service
providers can distribute RD independently. However, their special AS (Autonomous
System) number must be taken as a part of the RD to ensure that each RD is globally
unique. The VPN-IPv4 address with the RD of zero is synonymous with the IPv4
address that is globally unique. After being processed in this way, even if the 4-byte
IPv4 address contained in VPN-IPv4 address has been overlapped, the VPN-IPv4
address can still maintain globally unique. RD is only used within the carrier network to
differentiate routes. When the RD is 0, a VPN-IPv4 address is just a IPv4 address in
general sense.
The route received by PE from CE is the IPv4 route that needs to be redistributed into
vpn-instance routing table, and in this case a RD needs to be added. It is recommended
that the same RD be configured for the same VPN.
III. VPN Target attribute
VPN Target attribute is one of the MP-BGP extension community attributes and is used
to limit VPN routing information advertisement and receiving. It identifies the set of sites
that can use some route, namely by which Sites this route can be received, and the PE
router can receive the route transmitted by which Sites. The PE routers connected with
the Site specified in VPN Target can all receive the routes with this attribute. After PE
7-3
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
router has received the route with this attribute, it will add the route into the
corresponding routing table.
For PE routers, there are two sets of VPN Target attributes: one of them, referred to as
Export Targets, is added to the route received from a directly connected Site in
advertising local routes to remote PE routers. And the other one, known as Import
Targets, is used to decide which routes can be redistributed into the routing table of this
Site in receiving routings from remote PE routers.
In matching the VPN Target attribute carried by the route, if there are identical items in
the export VPN target set of the route and import VPN target set of the PE, the route is
redistributed into the VPN routing table and then advertised to the CE connected.
Otherwise, the route is rejected.
ERT: Export Route Targets
RD
IPv4 address
...
ERT1 ERT2
...
ERTn
MPLS VPN Route
Import Route Targets:
( IRT1, IRT2, ... ,IRTm )
Figure 7-2 Route filtering via matching VPN Target attribute
Note:
The routes for other VPNs will not appear in the routing table of the VPN in question
using VPN Target attribute to filter routing information received at PE router, so the
CE-transmitted data will only be forwarded within the VPN.
7.1.2 BGP/MPLS VPN Implementation
BGP/MPLS VPN works on this principle: It uses BGP to propagate VPN private routing
information on carrier backbone network and MPLS to forward VPN service traffic.
I. Advertising VPN routing information via BGP
1)
Routing information exchange between CE and PE
A PE router can learn routing information about the CE connected to it through static
route, RIP (supporting multi-instance), OSPF (supporting multi-instance) or EBGP, and
redistributes it into a vpn-instance.
7-4
Operation Manual – VPN
H3C SecPath Series Security Products
2)
Chapter 7 BGP/MPLS VPN Configuration
Routing information exchange between ingress PE and egress PE
The ingress PE router uses MP-BGP to advertise routing information learned from CE
to the egress PE router (with MPLS label) and learn the CE routing information learned
at the egress PE router.
The internal connectivity among all the PEs is ensured via IGP (for example, RIP and
OSPF), so IGP should run at all interconnection interfaces and loopback interfaces.
3)
LSP setup between PEs
LSPs should be set up between PEs for VPN data traffic forwarding with MPLS LSP.
The PE router that receives packets from CE and create label protocol stack is called
ingress LSR, while the BGP next hop (egress PE router) is egress LSR.
4)
Routing information exchange between PE and CE
A CE can learn remote VPN routes from the PE connected through static routes, RIP,
OSPF or EBGP.
With above-mentioned steps, reachable routes can be established between CEs, for
transmission of VPN private routing information over public network.
II. Forwarding VPN packets
VPN packets are forwarded by adopting two-layer label mode:
Interior-layer label, also called MPLS label, is at the bottom in label stack and
distributed when the egress PE advertises routing information (in VPN forwarding table)
to ingress GE. When VPN packets from public network reach the CE, they can be
forwarded from the designated interface to the designated CE or site by searching for
the target MPLS forwarding table according to the labels contained.
Exterior-layer label, known as LSP initialization label, is at the top in label stack and
indicates an LSP from the ingress PE to egress PE. By switching exterior-layer label,
VPN packets can be forwarded along the LSP to the peer PE.
Figure 7-3 illustrates the details:
Layer1
1.1.1.2
CE1
Layer2
Layer2
1.1.1.2
1.1.1.2
PE1
1.1.1.2
CE2
PE2
P
P
site1
site2
1.1.1.2/24
1.1.1.1/24
Figure 7-3 VPN packet forwarding
7-5
Operation Manual – VPN
H3C SecPath Series Security Products
1)
Chapter 7 BGP/MPLS VPN Configuration
Site 1 sends an IPv4 packet with destination address 1.1.1.2 to CE1. CE1 looks
routing information up in the IP routing table and sends the packet to PE1.
2)
PE1 looks up in the VPN-instance table according to the destination interface and
destination address to get MPLS label (or interior-layer label), LSP initialization
label (or exterior-layer label), BGP next hop (PE2), egress interface etc. When the
label stack is established, PE1 forwards via the egress interface the MPLS packet
to the first P on the LSP.
3)
Every P router on the LSP forwards the MPLS packet according to the
exterior-layer label until the packet reaches the penultimate router, i.e. the P router
right before the PE2, which extracts the exterior-layer label and forwards the
packet to PE2.
4)
PE2 looks up in the MPLS forwarding table according to the interior-layer label and
destination address to determine the egress interface for labeling operation and
the packet. It then extracts the interior-layer label and forwards through the egress
interface the IPv4 packet to CE2.
5)
CE2 looks up in the routing table and sends the packet in normal IPv4 packet
forwarding mode to the site2.
7.1.3 Introduction to Multi-Role Host Features
As the VPN attribute of a packet that enters PE from CE is determined by the VPN
bound with the incoming interface, it in essence determines that all the CEs that obtain
the forwarding service of PE via the same incoming interface must belong to the same
VPN. In the actual networking environments, however, there is the need for a CE to
access multiple VPNs via the same physical interface. Such a requirement can be
satisfied by setting different logical interfaces, but such a stopgap solution will increase
the extra configuration works and have great limit in application. In the process of
solving this problem, the concept of multi-role host was introduced. It distinguishes the
VPNs that the packets will access by configuring policy routing based on IP address. As
for the PE-CE downstream traffic, this function is implemented via static routing. The
static routing in a multi-role host application is different from the regular static routes in
the sense that it enables a logical interface to access multiple VPNs by making use of
the static route on a VPN to specify an interface in some other VPN as the outgoing
interface.
7.1.4 OSPF VPN Extension
I. OSPF multi-instance
As one of the most popular IGP routing protocols, OSPF is used as internal routing
protocol in many VPNs. If OSPF is also used on PE-CE links, then CE routers only
need to support OSPF protocol. If you want to transform conventional OSPF backbone
into BGP/MPLS VPN, the OSPF can simplify this process.
7-6
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
When OSPF is used as PE-CE routing protocol in BGP/MPLS VPN application,, PE
must support OSPF multi-instance, one OSPF instance corresponds to one VPN
instance. It owns its own interface, routing table and sends VPN routing information
over MPLS network using BGP/OSPF interaction.
The following involves details about the OSPF configuration between PE and CE.
1)
OSPF domain configuration between PE and CE
The OSPF domain between PE and CE can be a non-backbone area or a backbone
area.
In the application of OSPF VPN extension, the MPLS VPN backbone network is
considered as the backbone area (area 0). All the areas should be connected with the
backbone area in OSPF, so area 0 of all the VPN nodes must be connected with the
MPLS VPN backbone network.
That is, if a VPN node involves OSPF domain 0, the PE connected to CE must connect
with the backbone area of the VPN node through area 0 (The virtual link can be used
for logical connection).
2)
BGP/OSPF interaction
After OSPF runs between PE and CE, PE advertises VPN routes to other PEs through
BGP and to CEs through OSPF.
As shown in Figure 7-4, PE1 connects to PE2 through the MPLS backbone network.
CE11, CE21, and CE22 belong to VPN1. Suppose all the routers in the figure belong to
the same AS, that is, CE11, CE21, and CE22 belong to the same OSPF area.
The advertisement procedure of VPN1 routes is as follows:
z
BGP redistributes OSPF routes of CE11 on PE1.
z
BGP advertises the VPN routes to PE2.
z
OSPF redistributes BGP VPN routes on PE2, and advertises them to CE21 and
CE22.
7-7
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
VPN1
Site1
OSPF Area0
VPN1
Site2
OSPF Area1
CE11
CE21
Area 1
OSPF 100 VPN1
Area 0
OSPF 100 VPN1
PE1
MPLS VPN
Backbone
PE2
Area 1
OSPF 200 VPN1
Area 1
OSPF 200 VPN2
CE12
VPN2
Site1
OSPF Area1
CE22
VPN1
Site3
OSPF Area2
Figure 7-4 Application of OSPF in VPN
The standard BGP/OSPF interaction enables PE2 to advertise the BGP VPN routes to
CE21 and CE22 through Type5 LSAs (ASE LSAs). However, CE11, CE21, and CE22
belong to the same OSPF area, and the route advertisement between them depends
on Type3 LSAs (inter-domain routes).
To avoid the above cases, the PE applies a modified BGP/OSPF interaction process
(shorted as BGP/OSPF interoperability). It can advertise the routes from a Site to
another, and differentiate the routes from real AS-External routes. The process requires
the extension community attribute of BGP and the information identifying OSPF
attributes.
The Comware requires that each OSPF domain have a Domain ID. It is recommended
to configure a same Domain ID for all OSPF instances in the network related to each
VPN instance, or adopt the default ID 0. In this case, all the VPN routes with the same
Domain ID come from the same VPN instance.
3)
Routing loop detection
Suppose PE connects to CE through the OSPF backbone area, and a VPN Site
connects to multiple PEs. When a PE advertises BGP VPN routes learnt from
MPLS/BGP to a VPN Site through LSAs, the LSAs may possibly be received by
another PE, thus resulting in the routing loop.
To avoid the routing loop, the PE sets the flag bit DN for BGP VPN routes learnt from
MPLS/BGP when originating Type3 LSAs, regardless of whether PE connects to CE
through the OSPF backbone area. The PE ignores the Type3 LSAs for DN settings
during the route calculation of OSPF process.
To advertise a route from another OSPF domain to CE, the PE should claim an ASBR
and advertise the route as Type5 LSA. The VPN Route Tag configured for an OSPF
instance is contained in Type5 or Type7 LSAs. The PE ignores the Type5 or Type7 LSA
7-8
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
if the contained tag value is the same as that configured on PE during the route
calculation of OSPF process.
II. Multi-VPN-Instance CE
If supporting OSPF multi-instance, one router can run multiple OSPF procedures,
which can be bound to different VPN instances. In practice, you can create one OSPF
instance for each service type. OSPF multi-instance can fully isolate different services
in transmission, which can solve security problems with low cost. OSPF multi-instance
runs on PE router, which is called multi-VPN-instance CE. Currently, different services
in a LAN are often isolated with the VLAN function of a switch, but OSPF multi-instance
provides a solution for service isolation on routers.
Engineering
ospf 100
vpn-engineering
ospf 100
vpn-engineering
MPLS Network
PE
Router
opsf 200
opsf 200
vpn-rd
vpn-rd
ospf 300
vpn-finances
Multi-VPN-Instance CE
ospf 300
vpn-finances
R&D
Finances
Figure 7-5 Multi-VPN-instance CE application in conventional LAN
III. Sham Link
As shown in Figure 7-6, two Sites in a same OSPF domain connect to PE1 and PE2.
There is an OSPF link inside the area (called backdoor link) between the two Sites. The
two Sides belong to a same VPN. In this case, the route connecting the two Sites
through PEs is called the Inter-Area Route. It is not selected as the optimal route by
OSPF because its preference is lower than that of the Intra-Area Route across the
backdoor link.
Sham link
MPLS VPN Backbone
PE1
PE2
Area 1
OSPF 200 VPN1
Area 1
OSPF 200 VPN1
CE12
VPN1
Site1
OSPF Area1
CE22
CE12
Backdoor
Figure 7-6 Sham link application
7-9
VPN1
Site3
OSPF Area1
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
In some cases, the routes across the MPLS VPN backbone network need to be firstly
selected. You can establish a sham link between PEs to make the routes become the
Intra-Area Routes.
The sham link acts as an unnumbered point-to-point link inside the area and is
advertised using Type1 LSA. You can select a route between the sham link and
backdoor link by adjusting the metric.
The sham link is considered the link between two VPN instances with one endpoint
address in each VPN instance. The address is a Loopback interface address with a
32-bit mask in the VPN address space on the PE. The same OSPF process can share
endpoint addresses between sham links, while different OSPF processes cannot.
The BGP advertises the endpoint addresses of sham links as VPN-IPv4 addresses. A
route across the sham link cannot be redistributed into BGP as a VPN-IPv4 route.
The sham link can be configured in any area. You need to configure it manually in
Comware. In addition, the local VPN instance must contain a route to the destination of
sham link.
7.1.5 Multi-AS BGP/MPLS VPN
In some networking scenarios, a user’s multiple sites belong to the same VPN may
connect to multiple ISPs that use different ASs or connect to multiple ASs of an ISP.
Such application is called Multi-AS BGP/MPLS VPN.
RFC 2547bis presents three multi-AS VPN solutions, which are:
z
VPN-INSTANCE-to-VPN-INSTANCE: ASBRs manage VPN routes in between by
using subinterfaces, which is also called Inter-Provider Backbones Option A.
z
EBGP Redistribution of labeled VPN-IPv4 routes: ASBRs advertise labeled
VPN-IPv4 routes to each other through MP-EBGP, which is also called
Inter-Provider Backbones Option B.
z
Multihop EBGP redistribution of labeled VPN-IPv4 routes: PEs advertise labeled
VPN-IPv4 routes to each other through Multihop MP-EBGP, which is also called
Inter-Provider Backbones Option C.
The Comware supports the above three solutions.
I. Managing VPN routes between ASBRs by using subinterfaces
PEs, acting as ASBRs in two ASs, are directly connected.
ASBR PEs connect to each other through multiple subinterfaces. Considering each
other as their CE, the ASBR PEs advertise IPv4 routes to the peer using traditional
EBGP. Each subinterface is associated with a VPN. You need to bind the subinterfaces
on the ASBR to their corresponding VPN-instances but do not need to enable MPLS on
them. Within an AS, packets are forwarded as VPN packets using two-tier labels;
between ASBRs, they are forwarded using IP routing.
7-10
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Ideally, each multi-AS VPN has a pair of subinterfaces for exchanging VPN routing
information.
CE-1
VPN-1
CE-3
VPN-1
PE-1 BGP/MPLS backbone
AS 100
BGP/MPLS backbone PE-3
AS 200
MP-EBGP
ASBR-1
(PE)
MP-IBGP
PE-2
MP-IBGP
VPN LSP1
ASBR-2
(PE)
Sub-interface
Sub-interface
IP forwarding
LSP1
MP-IBGP
MP-IBGP
PE-4
VPN LSP2
LSP2
CE-2
VPN-2
CE-4
VPN-2
Figure 7-7 Network diagram for managing VPN routes between ASBRs by using
subinterfaces
This method is easily to implement. No special configuration is required on the ASBRs.
However, it has weak extensibility. Because ASBR PEs need to manage all VPN routes
and create VPN instances on a per-VPN basis. This will lead to excessive VPN-IPv4
routes on PEs, and poses high performance requirements for the PEs.
II. Advertising labeled VPN-IPv4 routes through MP-EBGP between ASBRs
Two ASBRs, through MP-EBGP, exchange labeled VPN-IPv4 routes that they obtain
from respective AS PEs.
The routes are advertised following the procedures below:
1)
PEs in AS1 advertise labeled VPN-IPv4 routes to ASBR PE of AS1 or the Route
Reflector (RR) of ASBR PE through MP-IBGP.
2)
ASBR PE advertises labeled VPN-IPv4 routes to ASBR PE of AS2 through
MP-EBGP.
3)
ASBR PE of AS2 advertises labeled VPN-IPv4 routes to PEs in AS2 or the RR of
ASBR PE through MP-IBGP.
In this way, special processing is needed for labeled VPN-IPv4 routes on ASBRs. So it
is also called ASBR extension method.
7-11
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
CE-1
VPN-1
CE-3
VPN-1
PE-1 BGP/MPLS backbone
AS 100
BGP/MPLS backbone PE-3
AS 200
ASBR-2
(PE)
ASBR-1
(PE)
MP-IBGP
PE-2
MP-IBGP
MP-EBGP
MP-IBGP
MP-IBGP
VPN LSP1
VPN LSP2
LSP1
PE-4
VPN LSP3
LSP2
CE-2
VPN-2
CE-4
VPN-2
Figure 7-8 Network diagram for advertising labeled VPN-IPv4 routes through
MP-EBGP between ASBRs
In terms of extensibility, advertising labeled VPN-IPv4 routes through MP-EBGP is prior
to managing VPN between ASBRs through subinterfaces.
When adopting MP-EBGP method, note that:
z
ASBRs perform no VPN-Target filtering on VPN-IPv4 routes that they receive from
each other. So the ISPs in different ASs that exchange VPN-IPv4 routes need to
reach a trust agreement on the route exchange.
z
VPN-IPv4 routes are exchanged only between VPN peers. A VPN user cannot
exchange VPN-IPv4 routes with the public network or with MP-EBGP peers with
whom it has not signed a trust agreement.
III. Advertising labeled VPN-IPv4 routes through multihop MP-EBGP between
PEs
The two methods above require ASBRs to participate in maintaining and distributing
VPN-IPv4 routes. When all ASs need to exchange a great amount of VPN routes,
ASBRs may become the bottleneck that prevents the extension of network.
One solution is to make PEs exchange VPN-IPv4 routes directly with each other,
without the participation of ASBRs.
Two ASBRs advertise labeled IPv4 routes to PEs in their respective ASs through
MP-IBGP.
ASBRs neither keep VPN-IPv4 routes nor advertise VPN-IPv4 routes in between.
ASBRs keep the labeled IPv4 routes of PEs in the AS and advertise them to the peers
in other ASs. The ASBR in the transit AS also advertises labeled IPv4 routes. Therefore,
an LSP is established between ingress PE and egress PE.
7-12
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
PEs in different ASs establish Multihop EBGP connections with each other and
exchange VPN-IPv4 routes.
CE-1
VPN-1
CE-3
VPN-1
BGP/MPLS backbone
AS 200
BGP/MPLS backbone
AS 100
PE-1
ASBR-2
(PE)
ASBR-1
(PE)
MP-IBGP
PE-2
PE-3
Multi-hop MP-EBGP
MP-IBGP
MP-EBGP
MP-IBGP
MP-IBGP
PE-4
Multi-hop MP-EBGP
VPN LSP
CE-2
VPN-2
CE-4
VPN-2
LSP
Figure 7-9 Network diagram for advertising labeled VPN-IPv4 routes through Multihop
MP-EBGP between PEs
To improve the extensibility, you can specify an RR in each AS to keep all VPN-IPv4
routes and exchange VPN-IPv4 routes with PEs in the AS. The RRs in two ASs
establish multi-AS VPNv4 connection with each other and advertise VPN-IPv4 routes,
as shown in the following figure.
CE-1
VPN-1
CE-3
VPN-1
PE-1 BGP/MPLS backbone
AS 100
MP-IBGP
RR-1
BGP/MPLS backbone PE-3
AS 200
ASBR-1
(PE)
ASBR-2
(PE)
RR-2
MP-IBGP
MP-EBGP
PE-2
MP-IBGP
MP-IBGP
PE-4
Multi-hop MP-EBGP
VPN LSP
CE-2
VPN-2
LSP
Figure 7-10 Network diagram for multi-AS VPN Option C adopting RR
7-13
CE-4
VPN-2
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
7.2 BGP/MPLS VPN Configuration
To configure MPLS VPN, you are required to complete the following procedures in
general:
z
Configure basic information on PE, CE and P.
z
Establish the logical or physical link with IP capabilities from PE to PE.
z
Advertise and update VPN network information.
I. CE
Only static route, RIP, OSPF or EBGP is configured for VPN routing information
exchange with the PE connected, without MPLS.
II. PE
It implements MPLS/BGP VPN core functions, so its configuration is a bit complicated,
including:
z
Configure MPLS basic capacity, joint maintenance of LSP with P or other PE
z
Configure BGP/MPLS VPN site, that is, VPN instance
z
Configure static route, RIP, OSPF or MP-EBGP, for VPN routing information
exchange with CE.
z
Configure IGP, for intra-PE interconnection.
z
Configure MP-IBGP, for VPN routing information exchange between PEs.
III. P
MPLS basic capacity is configured, to support LDP and MPLS forwarding.
The following are detailed configurations.
7.2.1 Configuring CE
Only basic configuration is required on CE, for routing information exchange with PE.
Currently route switching modes available include static route, RIP, OSPF, EBGP,
VLAN subinterface etc.
I. Configuring static route
If you select static route mode for CE-PE route switching, you should then configure a
private static route pointing to PE on CE.
Perform the following configuration in system view.
Table 7-1 Configure/delete static routes in the VPN-instance routing table
Operation
Create a specific
vpn-instance static route
Command
ip route-static ip-address { mask | mask-length }
{ interface-type interface-number | gateway-address }
[ preference preference-value ] [ reject | blackhole ]
7-14
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Operation
Delete a specific
vpn-instance static route
Command
undo ip route-static ip-address { mask |
mask-length } [interface-type interface-number |
gateway-address ] [ preference preference-value ]
You can also specify preference for a static route. By default, the preference value for a
static route is 60.
II. Configuring RIP
If you select RIP mode for CE-PE route switching, you should then configure RIP on CE.
For details about RIP configuration, see RIP Configuration section in Routing Protocol
module of this manual.
III. Configuring OSPF
If you select OSPF mode for CE-PE route switching, you should then configure OSPF
on CE. For details about OSPF configuration, see Routing Protocol module of this
manual.
IV. Configuring EBGP
If you select BGP mode for CE-PE route switching, you should then configure EBGP
peer, redistribute directly connected route, static route and other IGP routes, for BGP to
advertise VPN routes to PE.
7.2.2 Configuring PE
I. Configuring MPLS basic capacity
It includes configuring MPLS LSR ID, enabling global MPLS and enabling MPLS in
interface view.
See section MPLS Basic Capacity Configuration for details.
II. Defining VPN-instance
1)
Establish and enter vpn-instance view
The VPN instance is associated with the site. The VPN membership and routing rules
of a site is configured in the corresponding VPN instance.
This command is used to establish a new vpn-instance or enter the existing
vpn-instance view. If this vpn-instance already exists, then directly enter the view of this
vpn-instance to perform the corresponding configurations.
Perform the following configuration in system view.
7-15
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Table 7-2 Create and enter vpn-instance view
Operation
Command
Establish and enter vpn-instance view
ip vpn-instance vpn-instance_name
Delete vpn-instance
undo ip vpn-instance
vpn-instance_name
By default, no vpn-instance is defined.
2)
Configure RD for VPN instance
After PE is configured with RD, MP-BGP attaches the RD behind IPv4 when BGP is
redistributed at a VPN route learned at the CE. Then the general IPv4 address is turned
into a globally unique VPN IPv4 address.
Perform the following configuration in vpn-instance view.
Table 7-3 Configure RD for VPN instance
Operation
Command
Configure RD for VPN instance
route-distinguisher route-distinguisher
Here, no default value is set for the parameter.
Other parameters for VPN instance (except description information) cannot be
configured before configuring RD for it.
3)
Configure vpn-instance description
Perform the following configuration in vpn-instance view.
Table 7-4 Configure vpn-instance description
Operation
Command
Configure vpn-instance description
description vpn-instance-description
Delete vpn-instance description
undo description
4)
Configure vpn-target attribute for vpn-instance
VPN-target attribute, a BGP extension community attribute, controls advertisement of
VPN routing information.
It works on such principle:
z
When BGP redistributes a VPN route learned at CE, it associates a VPN-target
extension community attribute list with the route. Usually the list is the
VPN-instance output routing attribute list associated with CE.
7-16
Operation Manual – VPN
H3C SecPath Series Security Products
VPN
z
instance
Chapter 7 BGP/MPLS VPN Configuration
defines
input
routing
attribute
list
according
the
import-extcommunity in VPN-target, defining the range of routes that are
acceptable and can be redistributed.
VPN instance modifies VPN-target attributes for the routes to be advertised,
z
according to the export-extcommunity in VPN-target.
Like RD, an extension community includes an ASN plus an arbitrary number or an IP
address plus an arbitrary number. There are two types of formats:
16-bit ASN: 32-bit user-defined number, for example, 100:1.
32-bit IP address: 16-bit user-defined number, for example, 172.1.1.1:1.
Perform the following configuration in vpn-instance view.
Table 7-5 Configure vpn-target attribute for vpn-instance
Operation
Command
Establish vpn-target extension
community for vpn-instance
vpn-target vpn-target-extcommunity
[ import-extcommunity |
export-extcommunity | both ]
Delete the specified route-target
attribute from the vpn-target
attribute list
undo vpn-target vpn-target-extcommunity
[ import-extcommunity |
export-extcommunity | both ]
By default, the value is both. In general, all sites in a VPN can be interconnected, and
the import-extcommunity and export-extcommunity attributes are the same.
Up to 16 vpn-targets can be configured with a command, and up to 256 vpn-targets can
be configured for a VPN-INSTANCE.
5)
Limit the maximum route number in a vpn-instance
This command is used to limit the maximum route number for a vpn-instance to avoid
too many routes at the import of PE.
Perform the following configuration in vpn-instance view.
Table 7-6 Limit the maximum route number for a vpn-instance
Operation
Command
Limit the maximum route number for a
vpn-instance
routing-table limit threshold-value
{ warn-threshold | syslog-alert }
Remove maximum route number
limitation
undo routing-table limit
7-17
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Note:
Changing maximum route count for VPN-instance will not affect the existing routing
table. To make the new configuration take effect immediately, you should rebuild the
corresponding routing protocol or perform shutdown/undo shutdown operation on
the corresponding interface.
6)
Associate interface with vpn-instance
VPN instance is associated with the directly connected site through interface binding.
When the packets from the site reach the PE though the interface bound, then the PE
can look routing information (including next hop, label, egress interface etc.) up in the
corresponding VPN instance.
This command can associate a vpn-instance with an interface.
Perform the following configuration in interface view.
Table 7-7 Associate the interface with vpn-instance
Operation
Command
Associate the interface with
vpn-instance
ip binding vpn-instance
vpn-instance-name
Remove the association of the interface
with vpn-instance
undo ip binding vpn-instance
vpn-instance-name
Caution:
As executing the ip binding vpn-instance command on an interface will delete the IP
address of the interface, you must configure the IP address of the interface after
executing that command when you bind the interface with a vpn-instance.
III. Configuring PE-CE routing switch
These routing switch modes are available between PE and CE: static route, RIP, OSPF,
EBGP and VLAN subinterface.
1)
Configure static route on PE
You can configure a static route pointing to CE on PE for it to learn VPN routing
information from CE.
Perform the following configuration in system view.
7-18
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Table 7-8 Create/delete the static route in vpn-instance routing table
Operation
Command
Create a specific
vpn-instance static
route
ip route-static vpn-instance vpn-instance-name1
vpn-instance-name2 …destination--address { mask |
mask-length } { interface-type interface-number
[ nexthop-address ] | vpn-instance vpn-nexthop-name
vpn-nexthop- address | nexthop-address [ public ] }
[ preference preference-value ] [ reject | blackhole ]
Delete a specific
vpn-instance static
route
undo ip route-static vpn-instance vpn-instance-name1
vpn-instance-name2 … ip-address { mask | mask-length }
{ interface-type interface-number [ vpn-instance
vpn-nexthop-name vpn-nexthop-address | nexthop-address
[ public ] } [ preference preference-value ]
You can also specify preference for a static route. By default, the preference value for a
static route is 60.
2)
Configure RIP multi-instance
If you select RIP mode for CE-PE route switching, you should then specify running
environment for RIP instance on PE. With this command, you can enter RIP view and
redistribute and advertise RIP instance in the view.
Perform the following configuration in RIP view.
Table 7-9 Configure PE-CE RIP instance
Operation
Command
Create PE-CE RIP instance
ipv4-family [ unicast ] vpn-instance
vpn-instance-name
Delete PE-CE RIP instance
undo ipv4-family [ unicast ]
vpn-instance vpn-instance-name
Then configure the RIP multi-instance to induct IBGP routing.
For details about RIP configuration, see the Routing Protocol part of this manual.
3)
Configure EBGP on PE
If EBGP runs between PE and CE, you should then configure neighbor for each VPN
and redistribute IGP route into CE in the VPN-instance view of MP-BGP.
Step 1: Configure peer group
Perform the following configuration in VPN-instance view of MP-BGP.
7-19
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Table 7-10 Configure peer group
Operation
Command
Configure a peer group
group group-name [ internal | external ]
Delete the specified peer group
undo group group-name
By default, the peer group is configured as internal. When BGP mode is used for
PE-CE route switching, they often belong to different ASs, so you should configure
EBGP peer as external.
Step 2: Configure AS number for a specific neighbor
When EBGP mode is used for PE-CE route switching, you should configure AS number
for a specific neighbor for every CE VPN-instance.
Perform the following configuration in VPN-instance view of MP-BGP.
Table 7-11 Configure AS number for a specific neighbor
Operation
Command
peer group-name as-number as-number
Configure AS number for a
specific neighbor
peer peer-address group group-name
[ as-number as-number ]
Delete the AS number of a
specific neighbor
undo peer { group-name as-number |
peer-address }
Step3: Redistribute IGP route
To advertise correctly VPN routing information over public network to other PEs with
which BGP adjacency has been created, a PE must redistribute the VPN routing
information of the directly connected CE into its MBGP routing table.
For example, if a static route is used between PE and CE, PE must redistribute a static
route in VPN-instance view of MBGP (import-route static). If RIP is run between PE and
CE, PE must redistribute an RIP route in VPN-instance view of MBGP (import-route rip).
If BGP is run between PE and CE, MBGP redistributes a directly connected route.
Perform the following configuration in VPN-instance view of MBGP.
Table 7-12 Redistribute IGP routes
Operation
Command
Redistribute IGP routes
import-route protocol [ process-id ] [ med med ]
Remove IGP route distribution
undo import-route protocol
Step 4: Configure BGP in asynchronous mode
7-20
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Perform the following configuration in VPN-instance view of MBGP.
Table 7-13 Configure BGP asynchronous with IGP
Operation
Command
Configure BGP asynchronous with IGP
undo synchronization
By default, asynchronous mode is selected.
Step 5: Permit route loop configuration in Hub&Spoke networking (optional)
Normally, PE-CE configuration can be performed by specifying the AS number of the
peer; other configurations can be performed by keeping the system default value.
In the case of standard BGP, BGP tests routing loop via AS number to avoid generating
routing loop. In the case of Hub&Spoke networking, however, PE carries the AS
number of the local autonomous system when advertising the routing information to CE,
if EBGP is run between PE and CE. Accordingly, the updated routing information will
carry the AS number of the local autonomous system when route update is received
from CE. In this case, PE cannot receive the route update information.
This phenomenon can be avoided by configuring the peer allowas-loop command,
which permits the routing loop to pass through and makes PE still receive the route
update information containing the local AS number from CE.
Perform the following configuration in IPv4 address-family sub-view.
Table 7-14 Allow/disable routing loop
Operation
Command
Allow routing loop.
peer { group-name | peer-address } allow-as-loop
[number]
Disable routing loop
undo peer { group-name | peer-address } allow-as-loop
By default, the received route update information is not allowed to generate loop
information.
Step 6: Configure BGP attribute.
IV. Configuring PE-PE route switching
To exchange VPN-IPv4 routing information between PEs, you should configure
MP-IBGP on PEs.
Perform the following configuration in BGP view or VPN instance view.
1)
Configure IBGP
These steps are often required.
Step 1: Configure BGP as asynchronous.
7-21
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Step 2: Configure BGP neighbor.
Note that BGP adjacency is established through loopback interface and the sub-net
mask must be 32 bits.
Step 3: Permit BGP session over any operable TCP interface.
In general, BGP uses the best local address in TCP connection. To keep TCP
connection available even when the interface involved fails, you can permit BGP
session over any interface through which TCP connection can be set up.
Table 7-15 Permit BGP session over any operable TCP interface
Operation
Command
Permit BGP session over any operable
TCP interface
peer { peer-address | group-name }
connect-interface interface-type
interface-number
Use the best local address for TCP
connection
undo peer { peer-address |
group-name } connect-interface
BGP often uses the specified loopback interface to set up BGP adjacency with the peer.
This can reduce the impact of network flap, because loopback interfaces are always up.
2)
Configure MP-IBGP
Step 1: Enter MP-IBGP address family view.
Perform the following configuration in BGP view.
Table 7-16 Configure VPNv4 address family view
Operation
Command
Enter MBGP VPNv4 view
ipv4-family vpnv4 [ unicast ]
Exit MBGP VPNv4 view
undo ipv4-family vpnv4 [ unicast ]
Step 2: Configure MBGP neighbor
Configure MBGP internal neighbor in MBGP VPNv4 view.
Step 3: Activate peer (group)
By default, BGP neighbor is active while MBGP neighbor is inactive. You should
activate MBGP neighbor in VPNv4 view.
Step 4: Configure local address as next hop in route advertisement (optional)
It is not configured by default. When configuring in multi-AS VPN Option B mode, you
must configure the IBGP peers in each involved domain with this command.
Perform the following configuration in MPGP VPNv4 view.
7-22
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Table 7-17 Configure local address as next hop in route advertisement
Operation
Command
Configure its address as next hop in
route advertisement
peer group-name next-hop-local
Remove the configuration
undo peer group-name next-hop-local
Step 5: Transfer BGP update packet without AS number (optional)
Perform the following configuration in MPGP VPNv4 view.
Table 7-18 Transfer BGP update packet without AS number
Operation
Command
Transfer BGP update packet without AS
number
peer group-name public-as-only
Transfer BGP update packet with AS
number
undo peer group-name public-as-only
V. Configuring OSPF VPN extension
Configuration of OSPF VPN extension includes:
z
Running OSPF between PE and CE
z
Configuring Multi-VPN-Instance CE
z
Configuring sham link
1)
Configure OSPF multi-instance on PE
If you select OSPF mode for CE-PE route switching, you should then configure OSPF
multi-instance on PE. It should be noted that when OSPF routes and directly connected
routes are redistributed into VPN instance, BGP routes should also be redistributed into
OSPF. Here only OSPF multi-instance configuration is detailed.
Step 1: Configure OSPF procedure.
Perform the following configuration in system view.
Table 7-19 Configure OSPF procedure
Operation
Command
Configure an OSPF procedure
ospf process-id [ router-id router-id-number ]
[ vpn-instance vpn-instance-name ]
Delete an OSPF procedure
undo ospf process-id
By default, the procedure index is 1.
7-23
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Caution:
An OSPF procedure can only belong to one VPN instance, while one VPN instance
may contain multiple OSPF procedures. By default, an OSPF procedure belongs to
public network.
Step 2: Configure domain ID
Domain ID identifies an OSPF autonomous system (AS). Each procedure is configured
with one domain ID, but different procedures may have the same domain ID.
Table 7-20 Configure domain ID
Operation
Command
Configure domain ID
domain-id { id-number | id-addr }
Restore the default value
undo domain-id
By default, id-number is 0 and id-addr is 0.0.0.0.
It is recommended that all OSPF instances in VPN be configured with the same domain
ID or the default value 0.
Caution:
The configured value will not take effect unit the command reset ospf is executed.
Step 3: Configure tag for redistributed VPN route (optional)
If a VPN site is linked to multiple PEs, routing ring may be caused when the routes
learned by MPLS/BGP are received by another PE in being advertised by category-5/-7
LSA of a PE to the VPN site. To solve this problem, you should configure route-tag. It is
recommended to configure identical route-tag for the PEs in the same VPN.
Perform the following configuration in OSPF view.
Caution:
The configured value will not take effect unit the command reset ospf is executed.
7-24
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Table 7-21 Configure tag for redistributed VPN route
Operation
Command
Configure tag for an redistributed VPN route
route-tag tag-number
Restore the default value
undo route-tag
By default, the first two characters of tag-number are fixed to 0xD000 and the last two
ones are the AS number of the local BGP. For example, if the local BGP AS number is
100, the tag value in decimal is 3489661028. Tag-number is an integer in range of
0~4294967295.
2)
Configuring Multi-VPN-Instance CE
You may configure OSPF multi-instance to isolate the services of different VPNs.
After binding an OSPF process with a VPN instance on a CE firewall, you must
configure the following command in OSPF view.
Table 7-22 Configure a firewall as multi-VPN-instance CE
Operation
Command
Configure a firewall as
multi-VPN-instance CE
vpn-instance-capability simple
Remove the configuration
undo vpn-instance-capability
3)
Configuring a Sham-Link
Sham links are required between two CEs when backdoor links are set up between the
two PEs and service data is expected to be transmitted over MPLS backbone. A sham
link between two PEs is considered as a link in OSPF domain. Its source and
destination addresses are both the loopback interface address with 32-bit mask, but
this loopback interface should be bound to a VPN instance and directly connected
routes must be redistributed to BGP.
Perform the following configuration in OSPF domain view.
Table 7-23 Configure a sham-link
Operation
Command
Configure a sham-link
sham-link source-addr destination-addr [ cost
cost-value ] [ simple password | md5 keyid key ]
[ dead seconds ] [ hello seconds ] [ retransmit
seconds ] [ trans-delay seconds ]
Remove the sham-link
undo sham-link source-addr destination-addr
7-25
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
By default, the value of cost is 1, and the values of dead, hello, retransmit and
trans-delay are respectively 40, 10, 5 and 1 second.
VI. Configuring multi-role host attribute
After the configuration of the routing switch between PEs, configure these items on PE
to achieve multi-role application with the site connected.
Step 1: Configure VPN-instance.
In multi-role application, a site is connected to a PE through physical port, but it can
access multiple VPNs. So you need to configure multiple VPN-instances on the PE and
bind the site port with the desired VPNs. For details about VPN-instance configuration,
see II. Defining VPN-instance.
Step 2: Configure policy routing
If policy routing has been enabled and the route-policy conditions have been met, the
command in the following table can be used to specify the system to forward the
packets along the route found by looking up the configured vpn-name1, vpn-name2,
vpn-name3, vpn-name4, vpn-name5, and vpn-name6.
Perform the following configuration in route-policy view.
Table 7-24 Look up private forwarding route and make the forwarding
Operation
Command
Look up private forwarding route and
make the forwarding
apply access-vpn vpn-instance
[ vpn-name1 vpn-name2 … ]
Remove the lookup in the specified VPN
instances
undo apply access-vpn vpn-instance
[ vpn-name1 vpn-name2 … ]
Step 3: Configure a private static route
Configure a static route to specify an interface in another VPN as egress interface, so
that the packets from PE to CE can be returned directly to the site.
Perform the following configuration in system view.
Table 7-25 Configure static route
Operation
Configure a private
static route
Command
ip route-static vpn-instance vpn-instance-name1
vpn-instance-name2 … ip-address { mask | mask-length }
{ interface-type interface-number | [ vpn-instance
vpn-nexthop-name vpn-nexthop-address ] } [ preference
preference-value ] [ reject | blackhole ]
7-26
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Operation
Remove the static
route
Command
undo ip route-static vpn-instance vpn-instance-name1
vpn-instance-name2 … ip-address { mask | mask-length }
{ interface-type interface-number [ vpn-instance
vpn-nexthop-name vpn-nexthop- address ] } [ preference
preference-value ] [ reject | blackhole ]
VII. Configuring multi-AS BGP/MPLS VPN
Do following configuration to achieve the Multi-AS BGP/MPLS VPN after the
configuration of the routing switch between PEs.
1)
Configuring VPN-Target filtering
By default, PE performs VPN-Target filtering for the received VPNv4 routes. The routes
passing the filtering are added into the routing table, while the rest are discarded.
If PE acts as an ASBR, it needs to collect all the VPNv4 routing information and
advertise it to other ASBRs. In this case, PE accepts all the VPNv4 routing information
from its peers without filtering based on VPN-target.
Perform the following configuration in BGP-VPNv4 sub-address family view.
Table 7-26 Configure VPN-Target filtering
Operation
Command
Enable VPN-Target filtering for the
VPNv4 routing information
policy vpn-target
Disable VPN-Target filtering for the
VPNv4 routing information
undo policy vpn-target
The undo policy vpn-target command is only applied to ABSR PEs in multi-AS VPN
Option B.
2)
Configuring label processing on public network routes
In the Multihop MP-EBGP multi-AS VPN solution, you need to establish a multi-AS
VPN LSP. PEs and ASBRs exchange public network routes through carried MPLS label
information.
Through the route-policy, MPLS labels are assigned to those public network routes that
match certain conditions. Other routes are still common IPv4 routes.
Perform the following configuration in route-policy view.
7-27
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Table 7-27 Configure label processing on public network routes
Operation
Command
Assign MPLS labels to the public network routes that
match route-policy conditions
apply mpls-label
Remove the assigned MPLS labels
undo apply mpls-label
Configure to only receive/transmit the public network
routes with MPLS labels
if-match mpls-label
Remove the configuration of only receiving/sending
public network routes with MPLS labels
undo if-match
mpls-label
By default, public network routes do not carry MPLS labels and no route-policy is
defined.
The public network routes with MPLS labels are advertised by MP-BGP. According to
RFC 3107 (Carrying Label Information in BGP-4), the label mapping information of a
route can be piggybacked by advertising BGP Update messages of the route. This
capability is implemented through BGP extension attributes and requires BGP peers
processing labeled IPv4 routes.
Perform the following configuration in BGP view.
Table 7-28 Configure the capability for processing labeled IPv4 routes
Operation
Command
Enable the capability for processing
labeled IPv4 routes
peer group-name
label-route-capability
Disable the capability for processing
labeled IPv4 routes
undo peer group-name
label-route-capability
By default, BGP peers cannot process labeled IPv4 routes.
3)
Configuring invariable next hop when advertising routes
Generally, BGP Speaker changes the next hop to itself when advertising routes to
EBGP peers. In the networking application that adopts Multihop MP-EBGP multi-AS
VPN mode and uses RR to advertise VPNv4 routes, BGP Speaker cannot vary the next
hop when advertising VPNv4 routes between RRs.
Perform the following configuration in BGP view, BGP-VPNv4 sub-address family view,
BGP VPN instance view, or BGP-IPv4 multicast sub-address family view.
7-28
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Table 7-29 Configure invariable next hop when advertising routes
Operation
Command
Configure invariable next hop when
advertising routes to EBGP peers
peer group-name next-hop-invariable
Restore the default configuration
undo peer group-name
next-hop-invariable
By default, the next hop changes to BGP Speaker when sending routes to EBGP peers.
7.2.3 Configuring P
P does not maintain VPN routes, but do keep connection with public network and
coordinate with PE in creating LSPs. These configurations are required on P router:
Step 1: Configure MPLS basic capacity and enable LDP on the interfaces connecting P
router to PE router, for forwarding MPLS packets. For details, see Chapter 2 MPLS
Basic Capability Configuration in the MPLS module of this manual.
Step 2: Enable OSPF on the interfaces that connect P router to PE router and
redistribute directly connected routes. For details, see OSPF section in the Routing
Protocol part of this manual.
7.3 Displaying and Debugging BGP/MPLS VPN
I. Displaying VPN address information from BGP table
After the above configuration, execute display command in any view to display the
running of the VPNv4 information in BGP database configuration, and to verify the
effect of the configuration.
Table 7-30 Display VPN address information from BGP table
Operation
Display VPN
address
information from
BGP table
Command
display bgp vpnv4 { all | route-distinguisher rd-value |
vpn-instance vpn-instance-name } { group [ group-name ] |
network | peer [ ip-address1 | verbose ] | routing
[ ip-address2 | statistic ] [ label ] [ as-path-acl as-path-acl |
cidr | community [ community-number | no-advertise |
no-export | no-export-subconfed | whole-match ] |
community-list community-list [ whole-match ] |
different-origin-as | peer ip-address1 [ advertised |
received ] | regular-expression text ] }
7-29
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
II. Displaying IP routing table associated with vpn-instance
After the above configuration, you can execute display command in any view to
display the corresponding information in the IP routing tables related to vpn-instance,
and to verify the effect of the configuration.
Table 7-31 Display the IP routing table associated with vpn-instance
Operation
Command
Display the IP routing table associated
with vpn-instance
display ip routing-table vpn-instance
vpn-instance-name [ statistics |
[ ip-address ] [ verbose ] ]
III. Displaying vpn-instance related information
After finishing the above configuration, executing the display command in any view
can display the vpn-instance related information, including its RD, description, the
interfaces associated with it, and so on. You can view the information to verify the
configuration effect.
Table 7-32 Display the vpn-instance related information
Operation
Command
Display the vpn-instance related information,
including its RD, description, the interfaces
associated with it, and so on.
display ip vpn-instance
[ vpn-instance-name |
verbose ]
IV. Debugging information concerning processing BGP
Execute debugging command in user view for the debugging of the related
vpn-instance information.
Table 7-33 Debugging information concerning processing BGP
Operation
Command
Debug information
concerning processing
BGP
debugging bgp { { keepalive | mp-update | open |
packet | update | route-refresh } [ receive | send |
verbose ] } { all | event | normal }
Disable the debug
information
undo debugging bgp { { keepalive | mp-update |
open | packet | update | route-refresh } [ receive |
send | verbose ] } { all | event | normal }
7-30
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
V. Displaying MPLS l3vpn-lsp information
Table 7-34 Display MPLS l3vpn-lsp information
Operation
Command
Display information on MPLS L3VPN
LSPs.
display mpls l3vpn-lsp [ verbose]
[ include text ]
Display information on the
VPN-instances of MPLS L3VPN LSPs.
display mpls l3vpn-lsp [ vpn-instance
vpn-instance-name ] [ transit | egress |
ingress ] [include text | verbose ]
VI. Displaying sham link
Table 7-35 Display sham link
Operation
Command
Display sham link
display ospf [ process-id ] sham-link
7.4 BGP/MPLS VPN Configuration Example
7.4.1 Integrated BGP/MPLS VPN Networking
I. Network requirements
z
VPN-A includes CE1 and CE3; VPN-B includes CE2 and CE4
z
Subscribers in different VPNs cannot access each other. The VPN-target attribute
for VPN-A is 111:1 and that for VPN-B is 222:2.
z
PE and P use the firewalls, while CE is usually a mid-range or low-end device.
Note:
The configuration in this case is focused on:
z
Configure EBGP to exchange VPN routing information between CE and PE.
z
Configure OSPF for intra-PE communication between PEs.
z
Configure MP-IBGP to exchange VPN routing information between PEs.
7-31
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
II. Network diagram
Figure 7-11 Network diagram for integrated BGP/MPLS VPN
III. Configuration procedure
The following respectively describes the configurations on PE, CE and P.
1)
Configure CE1.
# Configure CE1 and PE1 as neighbors, import direct-connect routes and static routes
to import intra-CE1 VPN routes into BGP and advertise to PE1. CE1 connects PE1
through Ethernet0.
[CE1] interface ethernet 0
[CE1-Ethernet0] ip address 168.1.1.1 255.255.0.0
[CE1-Ethernet0] quit
[CE1] bgp 65410
[CE1-bgp] group 168 external
[CE1-bgp] peer 168.1.1.2 group 168 as-number 100
[CE1-bgp] import-route direct
[CE1-bgp] import-route static
Note:
The configurations on other three CEs (CE2 to CE4) are similar to that on CE1.
7-32
Operation Manual – VPN
H3C SecPath Series Security Products
2)
Chapter 7 BGP/MPLS VPN Configuration
Configure PE1
# Configure vpn-instance for VPN-A on PE1, as well as other associated attributes to
control advertisement of VPN routing information.
[PE1] ip vpn-instance vpna
[PE1-vpn-vpna] route-distinguisher 100:1
[PE1-vpn-vpna] vpn-target 111:1 both
[PE1-vpn-vpna] quit
# Configure PE1 and CE1 as EBGP neighbors, import CE1 VPN routes learned into
MBGP VPN-instance address family.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpna
[PE1-bgp-af-vpn-instance] group 168 external
[PE1-bgp-af-vpn-instance] peer 168.1.1.1 group 168 as-number 65410
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn-instance] quit
[PE1-bgp] quit
# Bind the interface Ethernet1/0/0 connecting PE1 and CE1 to the VPN-A. Note that
you should first configure association between the interface and VPN-instance, and
then the IP address.
[PE1] interface ethernet 1/0/0
[PE1-Ethernet1/0/0] ip binding vpn-instance vpna
[PE1-Ethernet1/0/0] ip address 168.1.1.2 255.255.0.0
[PE1-Ethernet1/0/0] quit
# Configure loopback interface. (For PE, the IP address for loopback interface must be
a host address with 32-bit mask, to prevent the route is aggregated and then LSP
cannot process correctly interior-layer labels.)
[PE1] interface loopback0
[PE1-LoopBack 0] ip address 202.100.1.1 255.255.255.255
[PE1-LoopBack 0] quit
# Configure MPLS basic capacity, enable LDP on the interface connecting PE1 and
PE2 and the interface connecting PE1 and PE3. Establish LSP and forward MPLS
packets.
[PE1] mpls lsr-id 202.100.1.1
[PE1] mpls
[PE1-mpls] mpls ldp
[PE1-mpls] quit
[PE1] interface Ethernet2/0/0
[PE1-Ethernet2/0/0] ip address 172.1.1.1 255.255.0.0
[PE1-Ethernet2/0/0] mpls
[PE1-Ethernet2/0/0] mpls ldp enable
7-33
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE1-Ethernet2/0/0] quit
# Enable OSPF on the interface connecting PE3 and P and the loopback interface,
import direct-connect routes.
[PE1] ospf
[PE1-ospf] area 0
[PE1-ospf-area-0.0.0.0] network 172.1.0.0 0.0.255.255
[PE1-ospf-area-0.0.0.0] network 202.100.1.1 0.0.0.0
[PE1-ospf-area-0.0.0.0] quit
[PE1-ospf] import-route direct
[PE1-ospf] quit
# Set up MP-IBGP adjacency between PEs to exchange intra-PE VPN routing
information. Activate the MP-IBGP peer in VPN v4 address family view.
[PE1] bgp 100
[PE1-bgp] group 202 internal
[PE1-bgp] peer 202.100.1.3 group 202
[PE1-bgp] peer 202.100.1.3 connect-interface loopback0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpn] peer 202 enable
[PE1-bgp-af-vpn] peer 202.100.1.3 group 202
[PE1-bgp-af-vpn] quit
[PE1-bgp] quit
3)
Configure P
# Configure MPLS basic capacity, enable LDP on the interfaces connecting P and PE
for MPLS packet forwarding.
[P] mpls lsr-id 172.1.1.2
[P] mpls
[P-mpls] mpls ldp
[P-mpls] quit
[P] interface Ethernet1/0/0
[P-Ethernet1/0/0] ip address 172.1.1.2 255.255.0.0
[P-Ethernet1/0/0] mpls
[P-Ethernet1/0/0] mpls ldp enable
[P-Ethernet1/0/0] interface Ethernet2/0/0
[P-Ethernet2/0/0] ip address 172.2.1.2 255.255.0.0
[P-Ethernet2/0/0] mpls
[P-Ethernet2/0/0] mpls ldp enable
[P-Ethernet2/0/0] interface Ethernet3/0/0
[P-Ethernet3/0/0] ip address 172.3.1.2 255.255.0.0
[P-Ethernet3/0/0] mpls
[P-Ethernet3/0/0] mpls ldp enable
[P-Ethernet3/0/0] interface Ethernet4/0/0
7-34
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[P-Ethernet4/0/0] ip address 172.4.1.2 255.255.0.0
[P-Ethernet4/0/0] mpls
[P-Ethernet4/0/0] mpls ldp enable
[P-Ethernet4/0/0] quit
# Enable OSPF protocol on the interfaces connecting P and PE, import direct-connect
route to achieve intra-PE communication.
[P] ospf
[P-ospf] area 0
[P-ospf-area-0.0.0.0] network 172.1.1.0 0.0.255.255
[P-ospf-area-0.0.0.0] network 172.2.1.0 0.0.255.255
[P-ospf-area-0.0.0.0] network 172.3.1.0 0.0.255.255
[P-ospf-area-0.0.0.0] network 172.4.1.0 0.0.255.255
[P-ospf-area-0.0.0.0] quit
[P-ospf] import-route direct
4)
Configure PE3.
Note:
The configuration on PE3 is similar to that on PE1, you should pay more attention to
VPN routing attribute setting on PE3 to get information about how to control
advertisement of a same VPN routing information (with same VPN-target) over MPLS
network.
# Create VPN-instance for VPN-A on PE3, configure correlative attributes to control
advertisement of VPN routing information.
[PE3] ip vpn-instance vpna
[PE3-vpn-vpna] route-distinguisher 100:3
[PE3-vpn-vpna] vpn-target 111:1 both
[PE3-vpn-vpna] quit
# Set up EBGP adjacency between PE3 and CE3, import intra-CE3 VPN routes
learned into MBGP VPN-instance address family.
[PE3] bgp 100
[PE3-bgp] ipv4-family vpn-instance vpna
[PE3-bgp-af-vpn-instance] group 168 external
[PE3-bgp-af-vpn-instance] peer 168.3.1.1 group 168 as-number 65430
[PE3-bgp-af-vpn-instance] import-route direct
[PE3-bgp-af-vpn-instance] quit
[PE3-bgp] quit
# Bind the interface Ethernet1/0/0 connecting PE3 and CE3 to VPN-A.
7-35
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE3] interface ethernet 1/0/0
[PE3-Ethernet1/0/0] ip binding vpn-instance vpna
[PE3-Ethernet1/0/0] ip address 168.3.1.2 255.255.0.0
[PE3-Ethernet1/0/0] quit
# Configure loopback interface.
[PE3] interface loopback0
[PE3-LoopBack 0] ip address 202.100.1.3 255.255.255.255
[PE3-LoopBack 0] quit
# Configure MPLS basic capacity, enable LDP on the interface connecting PE1 and
PE2 and the interface connecting PE1 and PE3. Establish LSP and forward MPLS
packets.
[PE3] mpls lsr-id 202.100.1.3
[PE3] mpls
[PE3-mpls] mpls ldp
[PE3-mpls] quit
[PE3] interface Ethernet 2/0/0
[PE3-Ethernet2/0/0] ip address 172.3.1.1 255.255.0.0
[PE3-Ethernet2/0/0] mpls
[PE3-Ethernet2/0/0] mpls ldp enable
[PE3-Ethernet2/0/0] quit
# Enable OSPF on the interface connecting PE3 and P and the loopback interface,
import direct-connect routes.
[PE3] ospf
[PE3-ospf-area-0.0.0.0] network 172.3.0.0 0.0.255.255
[PE3-ospf-area-0.0.0.0] network 202.100.1.3 0.0.0.0
[PE3-ospf-area-0.0.0.0] import-route direct
# Set up MP-IBGP adjacency between PEs to exchange intra-PE VPN routing
information.
[PE3] bgp 100
[PE3-bgp] group 202 internal
[PE3-bgp] peer 202.100.1.1 group 202
[PE3-bgp] peer 202.100.1.1 connect-interface loopback0
[PE3-bgp-af-vpn] peer 202 enable
[PE3-bgp-af-vpn] peer 202.100.1.1 group 202
[PE3-bgp-af-vpn] quit
5)
Configure PE2 and PE4
The configurations of PE2 and PE4 are similar to those of PE1 and PE3.
7-36
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
7.4.2 Configuring BGP/MPLS VPN using GRE Tunnel
I. Network requirements
z
VPN-A includes CE-1 and CE3; VPN-B includes CE-2 and CE-4.
z
PEs use the firewalls with MPLS capacity. P uses the firewall without MPLS
capacity required and CE is often a mid-range or low-end device.
II. Network diagram
P
192.168.1.0/24
CE-1
192.168.2.0/24
ether1/0/1
ethenet1/0/0
PE 1
CE-3
ethernet2/0/2 ethernet1/0/0
PE 2
L0:4.4.4.9/32
L0:1.1.1.9/32
AS 100
L0:2.2.2.9/32
CE-2
CE-4
Figure 7-12 Network diagram for BGP/MPLS VPN configuration using GRE tunnel
III. Configuration procedure
1)
Configure CE1
# Configure CE1 and PE1 as neighbors, import direct-connect routes and static routes
to import intra-CE1 VPN routes into BGP and advertise to PE1. CE1 connects PE1
through Ethernet0.
[CE1] interface ethernet 0
[CE1-Ethernet0] ip address 20.1.1.1 255.255.0.0
[CE1-Ethernet0] quit
[CE1] bgp 65410
[CE1-bgp] group 20 external
[CE1-bgp] peer 20.1.1.2 group 20 as-number 100
[CE1-bgp] import-route direct
[CE1-bgp] import-route static
Note:
The configurations on other three CEs (CE2 to CE4) are similar to that on CE1.
2)
Configure PE1
# Configure vpn-instance.
[PE1] ip vpn-instance vpna
7-37
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE1-vpn-vpna] route-distinguisher 100:1
[PE1-vpn-vpna] vpn-target 100:1 both
[PE1-vpn-vpna] quit
# Bind the interface Ethernet1/0/0 connecting PE1 and CE1 to the VPN-A.
[PE1] interface loopback0
[PE1-LoopBack0] ip address 1.1.1.9 255.255.255.255
[PE1-LoopBack0] quit
[PE1] interface ethernet 1/0/0
[PE1-Ethernet1/0/0] ip binding vpn-instance vpna
[PE1-Ethernet1/0/0] ip address 20.1.1.2 255.255.0.0
[PE1-LoopBack1/0/0] quit
[PE1] interface ethernet1/0/1
[PE1-Ethernet1/0/1] ip address 192.168.1.1 255.255.255.0
[PE1-Ethernet1/0/1] quit
# Configure PE1 and CE1 as EBGP neighbors, import VPN-instance interface routes.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpna
[PE1-bgp-af-vpn-instance] group 20 external
[PE1-bgp-af-vpn-instance] peer 20.1.1.1 group 20 as-number 65410
[PE1-bgp-af-vpn-instance] peer 20 next-hop-local
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn-instance] quit
[PE1-bgp] quit
# Set up MP-IBGP adjacency between PEs, for intra-PE VPN routing information
exchange, activate MP-IBGP peer in VPNv4 address family view.
[PE1] bgp 100
[PE1-bgp] group 2
[PE1-bgp] peer 2.2.2.9 group 2
[PE1-bgp] peer 2.2.2.9 connect-interface loopback0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpn] peer 2 enable
[PE1-bgp-af-vpn] peer 2.2.2.9 group 2
# Enable OSPF on the interface connecting PE1 and P and the loopback interface,
import direct-connect routes to achieve intra-AS communication.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[PE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] import-route direct
7-38
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
# Configure MPLS.
[PE1] mpls lsr-id 1.1.1.9
[PE1] mpls
[PE1-mpls] mpls ldp
# Configure GRE tunnel
[PE1] interface tunnel 1
[PE1-Tunnel1] tunnel-protocol gre
[PE1-Tunnel1] source loopback 0
[PE1-Tunnel1] destination 2.2.2.9
[PE1-Tunnel1] mpls
[PE1-Tunnel1] mpls ldp enable
[PE1-Tunnel1] mpls ldp transport-ip interface
Note:
z
The configuration of PE2 is similar to that on PE1.
z
The configuration of VPN_B is similar to that on VPN_A. However, you need to set a
unique route distinguisher for VPN_B, and set VPN target attribute correctly, thus to
ensure routes can only be imported to corresponding VPN instances.
3)
Configure P
# Configure interface.
[P] interface ethernet1/0/0
[P-ethernet1/0/0] ip address 192.168.1.2 255.255.255.0
[P] interface ethernet2/0/1
[P-ethernet2/0/1] ip address 192.168.2.2 255.255.255.0
# Enable OSPF protocol.
[P] ospf
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[P-ospf-1-area-0.0.0.0] network 192.168.2.0 0.0.0.255
[P-ospf-1-area-0.0.0.0] quit
[P-ospf-1] import-route direct
7.4.3 Extranet Networking
I. Network requirements
Both Company A and Company B are based in City C. They are interconnected with
VPN and respectively own VPN1 and VPN2.
7-39
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
MPLS provides VPN function. There are some shared resources at the City C for two
VPNs. All VPN subscribers can access the shared resources, but VPN subscribers in
City A and City B cannot access each other.
The two companies cannot use identical IP addresses, for they share the same
VPN-instance at PE-C.
Note:
In this example the configuration is focused on controlling access authority of VPN
subscribers at different cities by configuring different VPN-target attributes at different
PEs.
II. Network diagram
Service provider
network
AS100
PE-A
10.1.1.1
Ethernet1/0/0
172.15.0.1/16
PE-C
20.1.1.1
Ethernet1/0/0
172.16.0.1/16
Ethernet2/0/0
172.15.1.1/16
Ethernet2/0/0
172.16.1.1/16
PE-B
30.1.1.1
Ethernet1/0/0
172.17.0.1/16 Ethernet2/0/0
172.17.1.1/16
City A
AS65011
CE-A
City C
AS65012
CE-C
City B
AS65013
10.11.1.0/24
PC
CE-B
10.12.1.0/24
PC
PC
PC
VPN 1
PC
PC
PC
VPN 2
Figure 7-13 Extranet network diagram
7-40
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
III. Configuration procedure
Note:
The example omits the configuration of basic MPLS capacity between the PEs and
between the PE and P. For these details refer to the former example.
1)
Configure PE-A
# Configure VPN-instance for VPN1 on PE-A, so that it can receive VPN routing
information of VPN-target 111:1.
[PE-A] ip vpn-instance vpn1
[PE-A-vpn-vpn1] route-distinguisher 100:1
[PE-A-vpn-vpn1] vpn-target 111:1 both
[PE-A-vpn-vpn1] quit
# Set up EBGP adjacency between PE-A and CE-A, import intra-CE-A VPN routes
learned into MBGP VPN-instance address family.
[PE-A] bgp 100
[PE-A-bgp] ipv4-family vpn-instance vpn1
[PE-A-bgp-af-vpn-instance] group 172 external
[PE-A-bgp-af-vpn-instance] peer 172.15.1.1 group 172 as-number 65011
[PE-A-bgp-af-vpn-instance] import-route direct
[PE-A-bgp-af-vpn-instance] import-route static
[PE-A-bgp-af-vpn-instance] quit
[PE-A-bgp] quit
# Bind the interface Ethernet1/0/0 connecting CE-A with VPN-instance.
[PE-A] interface ethernet 1/0/0
[PE-A-Ethernet1/0/0] ip binding vpn-instance vpn1
[PE-A-Ethernet1/0/0] ip address 172.15.0.1 255.255.0.0
[PE-A-Ethernet1/0/0] quit
# Configure loopback interface.
[PE-A] interface loopback 0
[PE-A-LoopBack0] ip address 10.1.1.1 255.255.255.255
[PE-A-LoopBack0] quit
# Configure MPLS basic capacity.
[PE-A] mpls lsr-id 10.1.1.1
[PE-A] mpls
[PE-A-mpls] quit
[PE-A] mpls ldp
7-41
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
# Set up MP-IBGP adjacency between PEs to exchange intra-PE VPN routing
information. Activate the MP-IBGP peer in VPNv4 address family view.
[PE-A] bgp 100
[PE-A-bgp] group 20
[PE-A-bgp] peer 20.1.1.1 group 20
[PE-A-bgp] peer 20.1.1.1 connect-interface loopback 0
[PE-A-bgp] group 30
[PE-A-bgp] peer 30.1.1.1 group 30
[PE-A-bgp] peer 30.1.1.1 connect-interface loopback 0
[PE-A-bgp] ipv4-family vpnv4
[PE-A-bgp-af-vpn] peer 20 enable
[PE-A-bgp-af-vpn] peer 20.1.1.1 group 20
[PE-A-bgp-af-vpn] peer 30 enable
[PE-A-bgp-af-vpn] peer 30.1.1.1 group 30
[PE-A-bgp-af-vpn] quit
2)
Configure PE-C
# Create a VPN-instance on PE-C, so that it can transceive VPN routing information of
VPN-target 111:1 and 222:2.
[PE-C] ip vpn-instance vpn2
[PE-C-vpn-vpn2] route-distinguisher 100:2
[PE-C-vpn-vpn2] vpn-target 111:1
[PE-C-vpn-vpn2] vpn-target 222:2
[PE-C-vpn-vpn2] quit
# Set up EBGP adjacency between PE-C and CE-C, import intra-CE-C VPN routes
learned into MBGP VPN-instance address family.
[PE-C] bgp 100
[PE-C-bgp] ipv4-family vpn-instance vpn2
[PE-C-bgp-af-vpn-instance] group 172 external
[PE-C-bgp-af-vpn-instance] peer 172.16.1.1 group 172 as-number 65012
[PE-C-bgp-af-vpn-instance] import-route direct
[PE-C-bgp-af-vpn-instance] import-route static
[PE-C-bgp-af-vpn] quit
[PE-C-bgp] quit
# Bind the interface Ethernet1/0/0 connecting CE-C with VPN-instance.
[PE-C] interface ethernet 1/0/0
[PE-C-Ethernet1/0/0] ip binding vpn-instance vpn2
[PE-C-Ethernet1/0/0] ip address 172.16.0.1 255.255.0.0
# Configure loopback interface.
[PE-C] interface loopback 0
[PE-C-LoopBack0] ip address 20.1.1.1 255.255.255.255
7-42
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE-C-LoopBack0] quit
# Configure MPLS basic capacity.
[PE-C] mpls lsr-id 20.1.1.1
[PE-C] mpls
[PE-C-mpls] quit
[PE-C] mpls ldp
# Set up MP-IBGP adjacency between PEs to exchange intra-PE VPN routing
information. Activate the MP-IBGP peer in VPNv4 address family view.
[PE-C] bgp 100
[PE-C-bgp] group 10
[PE-C-bgp] peer 10.1.1.1 group 10
[PE-C-bgp] peer 10.1.1.1 connect-interface loopback 0
[PE-C-bgp] group 30
[PE-C-bgp] peer 30.1.1.1 group 30
[PE-C-bgp] peer 30.1.1.1 connect-interface loopback 0
[PE-C-bgp] ipv4-family vpnv4
[PE-C-bgp-af-vpn] peer 10 enable
[PE-C-bgp-af-vpn] peer 10.1.1.1 group 10
[PE-C-bgp-af-vpn] peer 30 enable
[PE-C-bgp-af-vpn] peer 30.1.1.1 group 30
[PE-C-bgp-af-vpn] quit
3)
Configure PE-B
# Create VPN-instance for VPN2 on PE-B, so that it can transceive VPN routing
information of VPN-target 222:2.
[PE-B] ip vpn-instance vpn3
[PE-B-vpn-vpn3] route-distinguisher 100:3
[PE-B-vpn-vpn3] vpn-target 222:2
[PE-B-vpn-vpn3] quit
# Set up EBGP adjacency between PE-B and CE-B, import intra-CE-B VPN routes
learned into MBGP VPN-instance address family.
[PE-B] bgp 100
[PE-B-bgp] ipv4-family vpn-instance vpn3
[PE-B-bgp-af-vpn-instance] group 172 external
[PE-B-bgp-af-vpn-instance] peer 172.17.1.1 group 172 as-number 65013
[PE-B-bgp-af-vpn-instance] import-route direct
[PE-B-bgp-af-vpn-instance] import-route static
[PE-B-bgp-af-vpn-instance] quit
[PE-B-bgp] quit
# Bind the interface Ethernet1/0/0 connecting CE-B with VPN-instance.
[PE-B] interface ethernet 1/0/0
7-43
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE-B-Ethernet1/0/0] ip binding vpn-instance vpn3
[PE-B-Ethernet1/0/0] ip address 172.17.0.1 255.255.0.0
[PE-B-Ethernet1/0/0] quit
# Configure loopback interface.
[PE-B] interface loopback 0
[PE-B-LoopBack0] ip address 30.1.1.1 255.255.255.255
[PE-B-LoopBack0] quit
# Configure MPLS basic capacity.
[PE-B] mpls lsr-id 30.1.1.1
[PE-B] mpls
[PE-B-mpls] quit
[PE-B] mpls ldp
# Set up MP-IBGP adjacency between PEs to exchange intra-PE VPN routing
information. Activate the MP-IBGP peer in VPNv4 address family view.
[PE-B] bgp 100
[PE-B-bgp] group 10
[PE-B-bgp] peer 10.1.1.1 group 10
[PE-B-bgp] peer 10.1.1.1 connect-interface loopback 0
[PE-B-bgp] group 20
[PE-B-bgp] peer 20.1.1.1 group 20
[PE-B-bgp] peer 20.1.1.1 connect-interface loopback 0
[PE-B-bgp] ipv4-family vpnv4
[PE-B-bgp-af-vpn] peer 10 enable
[PE-B-bgp-af-vpn] peer 10.1.1.1 group 10
[PE-B-bgp-af-vpn] peer 20 enable
[PE-B-bgp-af-vpn] peer 20.1.1.1 group 20
[PE-B-bgp-af-vpn] quit
7.4.4 Hub&Spoke Networking
I. Network requirements
Hub&Spoke networking is also called central server networking. The site in the center
is called hub-site, while the one not in the center is called spoke-site. The hub-site
knows the routes to all other sites in the same VPN, and the spoke-site must send its
traffic first to hub-site and then to the destination. Hub-site is the central node for
spoke-sites.
A bank has its headquarters network and subsidiary networks, and it requires that
subsidiaries cannot exchange data with each other, but through the headquarters
network. Hub&Spoke networking topology is used here: CE2 and CE3 are as
spoke-sites, while CE1 is as the hub-site of the bank data center. CE1 controls
communication between CE2 and CE3.
7-44
Operation Manual – VPN
H3C SecPath Series Security Products
z
Chapter 7 BGP/MPLS VPN Configuration
Set up IBGP adjacency between PE1 and PE2, between PE1 and PE3, but not
between PE2 and PE3, that is, VPN routing information cannot be exchanged
between PE2 and PE3.
z
Create two VPN-instances on PE1, import VPN routes of VPN-target 100:1, set
VPN-target for VPN routes advertised as 100:2.
z
Create one VPN-instance on PE2, import VPN routes of VPN-target 100:2, set
VPN-target for VPN routes advertised as 100:1.
z
Create one VPN-instance on PE3, import VPN routes of VPN-target 100:2, set
VPN-target for VPN routes advertised as 100:1.
Then PE2 and PE3 can only learn their neighbor’s routes through PE1.
Note:
In the case the configuration is focused on two points:
z
Route advertisement can be controlled by VPN-target settings on different PEs.
z
One routing loop is permitted, so that PE can receive route update messages with
AS number included from CE.
II. Network diagram
CE1
Hub Site
Ethernet1/0/0.2
172.17.0.1/16
Ethernet1/0/0.1
172.16.0.1/16
PE1
Loopback0
11.1.1.1/32
MPLS
Spoke Site
CE2
Spoke Site
PE3
20.1.1.2
PE2
Ethernet1/0/0
172.15.0.1/16
Loopback0
22.1.1.1/32
Figure 7-14 Hub&Spoke network diagram
7-45
Loopback0
33.1.1.1/32
Ethernet1/0/0
172.18.0.1/16
CE3
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
III. Configuration procedure
Note:
The example omits the configuration of basic MPLS capacity between the PEs and CE
configuration. See 7.4.1 “Integrated BGP/MPLS VPN Networking” for details.
1)
Configure PE1
# Configure two VPN-instances on PE1, set specified VPN-target for the routes
received from PE2 and PE3.
[PE1] ip vpn-instance vpn-instance2
[PE1-vpn-vpn-instance2] route-distinguisher 100:2
[PE1-vpn-vpn-instance2] vpn-target 100:1 import-extcommunity
[PE1-vpn-vpn-instance2] quit
[PE1] ip vpn-instance vpn-instance3
[PE1-vpn-vpn-instance3] route-distinguisher 100:3
[PE1-vpn-vpn-instance3] route-target 100:2 export-extcommunity
[PE1-vpn-vpn-instance3] quit
# Set up EBGP adjacency between PE1 and CE1, import intra-CE1 VPN routes
learned into MBGP VPN-instance address family, with one routing loop permitted.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn-instance2
[PE1-bgp-af-vpn-instance] group 17216 external
[PE1-bgp-af-vpn-instance] peer 172.16.1.1 group 17216 as-number 65002
[PE1-bgp-af-vpn-instance] peer 172.16.1.1 allow-as-loop 1
[PE1-bgp-af-vpn-instance] import-route static
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn] quit
[PE1-bgp] ipv4-family vpn-instance vpn-instance3
[PE1-bgp-af-vpn-instance] group 17217 external
[PE1-bgp-af-vpn-instance] peer 172.17.1.1 group 17217 as-number 65002
[PE1-bgp-af-vpn-instance] peer 172.17.1.1 allow-as-loop 1
[PE1-bgp-af-vpn-instance] import-route static
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn-instance] quit
[PE1-bgp] quit
# Bind the interface connecting PE1 and CE1 to different VPN-instances. # Bind the
interface Ethernet1/0/0.1 with VPN-instance 2 and interface Ethernet1/0/0.2 with
VPN-instance 3.
7-46
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE1] interface ethernet 1/0/0.1
[PE1-Ethernet1/0/0.1] ip binding vpn-instance vpn-instance2
[PE1-Ethernet1/0/0.1] ip address 172.16.0.1 255.255.0.0
[PE1-Ethernet1/0/0.1] quit
[PE1] interface ethernet 1/0/0.2
[PE1-Ethernet1/0/0.2] ip binding vpn-instance vpn-instance3
[PE1-Ethernet1/0/0.2] ip address 172.17.0.1 255.255.0.0
[PE1-Ethernet1/0/0.2] quit
# Configure loopback interface.
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 11.1.1.1 255.255.255.255
[PE1-LoopBack0] quit
# Set up MP-IBGP adjacency between PEs to exchange intra-PE VPN routing
information. Activate the MP-IBGP peer in VPNv4 address family view.
[PE1] bgp 100
[PE1-bgp] group 22
[PE1-bgp] peer 22.1.1.1 group 22
[PE1-bgp] peer 22.1.1.1 connect-interface loopback 0
[PE1-bgp] group 33
[PE1-bgp] peer 33.1.1.1 group 33
[PE1-bgp] peer 33.1.1.1 connect-interface loopback 0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpn] peer 22 enable
[PE1-bgp-af-vpn] peer 22.1.1.1 group 22
[PE1-bgp-af-vpn] peer 33 enable
[PE1-bgp-af-vpn] peer 33.1.1.1 group 33
[PE1-bgp-af-vpn] quit
2)
Configure PE2
# Create a VPN-instance on PE2, import VPN routing information of VPN-target 100:2
and advertise VPN routing information of VPN-target 100:1.
[PE2] ip vpn-instance vpn-instance1
[PE2-vpn-vpn-instance1] route-distinguisher 100:1
[PE2-vpn-vpn-instance1] route-target 100:1 export-extcommunity
[PE2-vpn-vpn-instance1] route-target 100:2 import-extcommunity
[PE2-vpn-vpn-instance1] quit
# Set up EBGP adjacency between PE2 and CE2, import intra-CE2 VPN routes
learned into MBGP VPN-instance address family.
[PE2] bgp 100
[PE2-bgp] ipv4-family vpn-instance vpn-instance1
[PE2-bgp-af-vpn-instance] group 172 external
7-47
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE2-bgp-af-vpn-instance] peer 172.15.1.1 group 172 as-number 65001
[PE2-bgp-af-vpn-instance] import-route static
[PE2-bgp-af-vpn-instance] import-route direct
[PE2-bgp-af-vpn-instance] quit
[PE2-bgp] quit
# Bind the interface connecting PE2 and CE2 with VPN-instance.
[PE2] interface ethernet 1/0/0
[PE2-Ethernet1/0/0] ip binding vpn-instance vpn-instance1
[PE2-Ethernet1/0/0] ip address 172.15.0.1 255.255.0.0
[PE2-Ethernet1/0/0] quit
# Configure loopback interface.
[PE2] interface loopback 0
[PE2-LoopBack0] ip address 22.1.1.1 255.255.255.255
[PE2-LoopBack0] quit
# Set up MP-IBGP adjacency between PEs to exchange intra-PE VPN routing
information. Activate the MP-IBGP peer in VPNv4 address family view.
[PE2] bgp 100
[PE2] group 11
[PE2-bgp] peer 11.1.1.1 group 11
[PE2-bgp] peer 11.1.1.1 connect-interface loopback 0
[PE2-bgp] ipv4-family vpnv4
[PE2-bgp-af-vpn] peer 11 enable
[PE2-bgp-af-vpn] peer 11.1.1.1 group 11
[PE2-bgp-af-vpn] quit
[PE2-bgp] quit
3)
Configure PE3
# Create a VPN-instance on PE3, import VPN routing information of VPN-target 100:2
and advertise VPN routing information of VPN-target 100:1.
[PE3] ip vpn-instance vpn-instance2
[PE3-vpn-vpn-instance2] route-distinguisher 100:1
[PE3-vpn-vpn-instance2] route-target 100:1 export-extcommunity
[PE3-vpn-vpn-instance2] route-target 100:2 import-extcommunity
[PE3-vpn-vpn-instance2] quit
# Set up EBGP adjacency between PE3 and CE3 import intra-CE3 VPN routes learned
into MBGP VPN-instance address family.
[PE3] bgp 100
[PE3-bgp] ipv4-family vpn-instance vpn-instance1
[PE3-bgp-af] group 172 external
[PE3-bgp-af-vpn-instance] peer 172.18.1.1 group 172 as-number 65001
[PE3-bgp-af-vpn-instance] import-route static
7-48
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE3-bgp-af-vpn-instance] import-route direct
[PE3-bgp-af-vpn] quit
[PE3-bgp] quit
# Bind the interface connecting PE3 and CE3 with VPN-instance.
[PE3] interface ethernet 1/0/0
[PE3-Ethernet1/0/0] ip binding vpn-instance vpn-instance2
[PE3-Ethernet1/0/0] ip address 172.18.0.1 255.255.0.0
[PE3-Ethernet1/0/0] quit
# Configure loopback interface.
[PE3] interface loopback 0
[PE3-LoopBack0] ip address 33.1.1.1 255.255.255.255
[PE3-LoopBack0] quit
# Set up MP-IBGP adjacency between PEs to exchange intra-PE VPN routing
information. Activate the MP-IBGP peer in VPNv4 address family view.
[PE3] bgp 100
[PE3-bgp] group 11
[PE3-bgp] peer 11.1.1.1 group 11
[PE3-bgp] peer 11.1.1.1 connect-interface loopback 0
[PE3-bgp] ipv4-family vpnv4
[PE3-bgp-af-vpn] peer 11 enable
[PE3-bgp-af-vpn] peer 11.1.1.1 group 11
[PE3-bgp-af-vpn] quit
[PE3-bgp] quit
7.4.5 CE Dual-Homed Networking
I. Network requirements
For the applications which require high robustness of network, you may use CE
dual-homed networking mode.
CE1 and CE2 are respectively connected to PE1 and PE2 to achieve dual-homed
configuration. Three PEs are also connected to each other as back links. CE3 and CE4
are not in dual-homed mode, and only connected to one PE.
CE1 and CE3 are in one VPN, and CE2 and CE4 are in another VPN. Two VPNs
cannot access each other.
7-49
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
II. Network diagram
AS:65003
AS:65004
CE3
CE4
Ethernet1/0/0
192.168.13.2/24
Ethernet3/0/0
192.168.13.1/24
Ethernet1/0/0
192.168.23.2/24
Loopback0
3.3.3.3/32
Ethernet1/0/0
30.1.1.1/24
Ethernet4/0/0
192.168.23.1/24
Ethernet2/0/0
20.1.1.2/24
PE3
Ethernet4/0/0
30.1.1.2/24
Loopback0
1.1.1.1/32
Ethernet1/0/0
172.11.11.1/24
Ethernet1/0/0
172.11.11.2/24
Ethernet3/0/0
10.1.1.1/24
PE1
Ethernet4/0/0
20.1.1.1/24
AS:100
Loopback0
2.2.2.2/32
Ethernet3/0/0
10.1.1.2/24
Ethernet2/0/0
172.21.21.1/24
Ethernet2/0/0
172.12.12.1/24
Ethernet2/0/0
172.12.12.2/24
PE2
Ethernet2/0/0
172.21.21.2/24
Ethernet1/0/0
172.22.22.1/24
Ethernet1/0/0
172.22.22.2/24
CE2
CE1
AS:65001
AS:65002
Figure 7-15 CE dual-homed networking diagram
III. Configuration procedure
Note:
The configuration of CE is omitted in this case and you can refer to 7.4.1 “Integrated
BGP/MPLS VPN Networking”.
1)
Configure PE1
# Configure two VPN-instances 1.1 and 1.2 respectively for CE1 and CE2 on PE1, set
different VPN-targets for them.
[PE1] ip vpn-instance vpn-instance1.1
[PE1-vpn-vpn-instance1.1] route-distinguisher 1.1.1.1:1
[PE1-vpn-vpn-instance1.1] route-target 1.1.1.1:1
[PE1-vpn-vpn-instance1.1] vpn-target 2.2.2.2:1 import-extcommunity
[PE1-vpn-vpn-instance1.1] vpn-target 3.3.3.3:1 import-extcommunity
[PE1-vpn-vpn-instance1.1] quit
[PE1] ip vpn-instance vpn-instance1.2
[PE1-vpn-vpn-instance1.2] route-distinguisher 1.1.1.1:2
7-50
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE1-vpn-vpn-instance1.2] route-target 1.1.1.1:2
[PE1-vpn-vpn-instance1.2] vpn-target 2.2.2.2:2 import-extcommunity
[PE1-vpn-vpn-instance1.2] vpn-target 3.3.3.3:2 import-extcommunity
[PE1-vpn-vpn-instance1.2] quit
# Set up EBGP adjacency between PE1 and CE1, import intra-CE1 VPN routes
learned into VPN-instance 1.1.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn-instance1.1
[PE1-bgp-af-vpn-instance] group 17211 external
[PE1-bgp-af-vpn-instance] peer 172.11.11.2 group 17211 as-number 65001
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn-instance] import-route static
[PE1-bgp-af-vpn] quit
[PE1-bgp] quit
# Set up EBGP adjacency between PE1 and CE2, import intra-CE2 VPN routes
learned into VPN-instance 1.2.
[PE1-bgp] ipv4-family vpn-instance vpn-instance1.2
[PE1-bgp-af-vpn-instance] group 17221 external
[PE1-bgp-af-vpn-instance] peer 172.21.21.2 group 17221 as-number 65002
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn-instance] import-route static
[PE1-bgp-af-vpn] quit
[PE1-bgp] quit
# Bind the interface connecting PE1 and CE1 with VPN-instance 1.1 and interface
connecting PE1 and CE2 with VPN-instance 1.2.
[PE1] interface ethernet 1/0/0
[PE1-Ethernet1/0/0] ip binding vpn-instance vpn-instance1.1
[PE1-Ethernet1/0/0] ip address 172.11.11.1 255.255.255.0
[PE1-Ethernet1/0/0] quit
[PE1] interface ethernet 2/0/0
[PE1-Ethernet2/0/0] ip binding vpn-instance vpn-instance1.2
[PE1-Ethernet2/0/0] ip address 172.21.21.1 255.255.255.0
[PE1-Ethernet2/0/0] quit
# Configure loopback interface.
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 1.1.1.1 255.255.255.255
[PE1-LoopBack0] quit
# Configure MPLS basic capacity, enable LDP on the interface connecting PE1 and
PE2 and the interface connecting PE1 and PE3.
[PE1] mpls lsr-id 1.1.1.1
7-51
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE1] mpls
[PE1-mpls] mpls ldp
[PE1-mpls] quit
[PE1] interface Ethernet 3/0/0
[PE1-Ethernet3/0/0] mpls
[PE1-Ethernet3/0/0] mpls ldp enable
[PE1-Ethernet3/0/0] ip address 10.1.1.1 255.255.255.0
[PE1-Ethernet3/0/0] interface Ethernet 4/0/0
[PE1-Ethernet4/0/0] mpls
[PE1-Ethernet4/0/0] mpls ldp enable
[PE1-Ethernet4/0/0] ip address 30.1.1.2 255.255.255.0
[PE1-Ethernet4/0/0] quit
# Enable OSPF on the interface connecting PE1 and PE2 and the interface connecting
PE1 and PE3 and the loopback interface, to achieve intra-PE communication.
[PE1] router id 1.1.1.1
[PE1] ospf
[PE1-ospf] area 0
[PE1-ospf-area-0.0.0.0] network 1.1.1.1 0.0.0.0
[PE1-ospf-area-0.0.0.0] network 30.1.1.2 0.0.0.255
[PE1-ospf-area-0.0.0.0] network 10.1.1.1 0.0.0.255
[PE1-ospf-area-0.0.0.0] quit
[PE1-ospf] quit
# Set up MP-IBGP adjacency between PEs to exchange intra-PE VPN routing
information. Activate the MP-IBGP peer in VPNv4 address family view.
[PE1] bgp 100
[PE1-bgp] group 2
[PE1-bgp] peer 2.2.2.2 group 2
[PE1-bgp] peer 2.2.2.2 connect-interface loopback 0
[PE1-bgp] group 3
[PE1-bgp] peer 3.3.3.3 group 3
[PE1-bgp] peer 3.3.3.3 connect-interface loopback 0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpn] peer 2 enable
[PE1-bgp-af-vpn] peer 2.2.2.2 group 2
[PE1-bgp-af-vpn] peer 3 enable
[PE1-bgp-af-vpn] peer 3.3.3.3 group 3
[PE1-bgp-af-vpn] quit
2)
Configure PE2
7-52
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Note:
The configuration of PE2 is similar to that of PE1, so only VPN-instance configuration is
detailed here.
# Create two VPN-instances 2.1 and 2.2 respectively for CE1 and CE2 on PE2,
configure different VPN-targets for them.
[PE2] ip vpn-instance vpn-instance2.1
[PE2-vpn-vpn-instance2.1] route-distinguisher 2.2.2.2:1
[PE2-vpn-vpn-instance2.1] vpn-target 2.2.2.2:1
[PE2-vpn-vpn-instance2.1] vpn-target 1.1.1.1:1 import-extcommunity
[PE2-vpn-vpn-instance2.1] vpn-target 3.3.3.3:1 import-extcommunity
[PE2-vpn-vpn-instance2.1] quit
[PE2] ip vpn-instance vpn-instance2.2
[PE2-vpn-vpn-instance2.2] route-distinguisher 2.2.2.2:2
[PE2-vpn-vpn-instance2.2] vpn-target 2.2.2.2:2
[PE2-vpn-vpn-instance2.2] vpn-target 1.1.1.1:2 import-extcommunity
[PE2-vpn-vpn-instance2.2] vpn-target 3.3.3.3:2 import-extcommunity
[PE2-vpn-vpn-instance2.2] quit
# Set up EBGP adjacency between PE2 and CE1, import intra-CE1 VPN routes
learned into VPN-instance2.1.
[PE2] bgp 100
[PE2-bgp] ipv4-family vpn-instance vpn-instance2.1
[PE2-bgp-af-vpn-instance] group 17212 external
[PE2-bgp-af-vpn-instance] peer 172.12.12.2 group 17212 as-number 65001
[PE2-bgp-af-vpn-instance] import-route direct
[PE2-bgp-af-vpn-instance] import-route static
[PE2-bgp-af-vpn-instance] quit
# Set up EBGP adjacency between PE2 and CE2, import intra-CE2 VPN routes
learned into VPN-instance2.2.
[PE2-bgp] ipv4-family vpn-instance vpn-instance2.2
[PE2-bgp-af-vpn-instance] group 17222 external
[PE2-bgp-af-vpn-instance] peer 172.22.22.2 group 17222 as-number 65002
[PE2-bgp-af-vpn-instance] import-route direct
[PE2-bgp-af-vpn-instance] import-route static
[PE2-bgp-af-vpn] quit
[PE2-bgp] quit
# Bind the interface connecting PE2 and CE1 with VPN-instance 2.1 and the interface
connecting PE2 and CE2 with VPN-instance 2.2.
[PE2] interface ethernet 2/0/0
7-53
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE2-Ethernet2/0/0] ip binding vpn-instance vpn-instance2.1
[PE2-Ethernet2/0/0] ip address 172.12.12.1 255.255.255.0
[PE2-Ethernet2/0/0] quit
[PE2] interface ethernet 1/0/0
[PE2-Ethernet1/0/0] ip binding vpn-instance vpn-instance2.2
[PE2-Ethernet1/0/0] ip address 172.22.22.1 255.255.255.0
[PE2-Ethernet1/0/0] quit
3)
Configure PE3.
Note:
Only VPN-instance configuration is detailed here for PE3, and others are similar to
those of PE1 and PE2.
# Create two VPN-instances 3.1 and 3.2 respectively for CE3 and CE4 on PE3,
configure different VPN-targets for them.
[PE3] ip vpn-instance vpn-instance3.1
[PE3-vpn-vpn-instance3.1] route-distinguisher 3.3.3.3:1
[PE3-vpn-vpn-instance3.1] vpn-target 3.3.3.3:1
[PE3-vpn-vpn-instance3.1] vpn-target 1.1.1.1:1 import-extcommunity
[PE3-vpn-vpn-instance3.1] vpn-target 2.2.2.2:1 import-extcommunity
[PE3-vpn-vpn-instance3.1] quit
[PE3] ip vpn-instance vpn-instance3.2
[PE3-vpn-vpn-instance3.2] route-distinguisher 3.3.3.3:2
[PE3-vpn-vpn-instance3.2] vpn-target 3.3.3.3:2
[PE3-vpn-vpn-instance3.2] vpn-target 1.1.1.1:2 import-extcommunity
[PE3-vpn-vpn-instance3.2] vpn-target 2.2.2.2:2 import-extcommunity
[PE3-vpn-vpn-instance3.2] quit
# Set up EBGP adjacency between PE3 and CE3, import intra-CE3 VPN routes
learned into VPN-instance3.1.
[PE3] bgp 100
[PE3-bgp] ipv4-family vpn-instance vpn-instance3.1
[PE3-bgp-af-vpn-instance] group 192 external
[PE3-bgp-af-vpn-instance] peer 192.168.13.2 group 192 as-number 65003
[PE3-bgp-af-vpn-instance] import-route direct
[PE3-bgp-af-vpn-instance] import-route static
[PE3-bgp-af-vpn] quit
[PE3-bgp] quit
# Set up EBGP adjacency between PE3 and CE4, import intra-CE4 VPN routes
learned into VPN-instance3.2.
7-54
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE3-bgp] ipv4-family vpn-instance vpn-instance3.2
[PE3-bgp-af-vpn-instance] group 232 external
[PE3-bgp-af-vpn-instance] peer 192.168.23.2 group 232 as-number 65004
[PE3-bgp-af-vpn-instance] import-route direct
[PE3-bgp-af-vpn-instance] import-route static
[PE3-bgp-af-vpn-instance] quit
[PE3-bgp] quit
# Bind the interface connecting PE3 and CE3 with VPsN-instance3.1 and the interface
connecting PE3 and CE2 with VPN-instance 3.2.
[PE3] interface ethernet 3/0/0
[PE3-Ethernet3/0/0] ip binding vpn-instance vpn-instance3.1
[PE3-Ethernet3/0/0] ip address 192.168.13.1 255.255.255.0
[PE3-Ethernet3/0/0] quit
[PE3] interface ethernet 4/0/0
[PE3-Ethernet4/0/0] ip binding vpn-instance vpn-instance3.2
[PE3-Ethernet4/0/0] ip address 192.168.23.1 255.255.255.0
[PE3-Ethernet4/0/0] quit
7.4.6 Multi-Role Host Networking
I. Network requirements
A company provides VPN service with BGP/MPLS VPN.
The interface Serial1/0/0 connecting PE1 and CE1 is bound with VPN1 and the
interface Serial0/0/0 connecting PE2 and CE2 is bound with VPN2.
PC1, with IP address 100.1.1.2, is accessed into the VPN1 and VPN 2 through CE1.
Note:
In the case, the configuration is focused on this point:
With proper configuration of static route and routing policy, PC1 can access packets in
different VPNs and search routes in different VPN-instances.
7-55
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
II. Network diagram
PE1 Ethernet1/0/0:
2.1.1.1/24
Ethernet0/0/0:
1.1.1.2/24
CE1
Ethernet0/0/0:
1.1.1.1/24
PE2
Ethernet1/0/0:
2.1.1.2/24 Ethernet0/0/0:
3.1.1.1/24
Ethernet2/0/0:
100.1.1.1/24
Ethernet0/0/0:
3.1.1.2/24
CE2
Ethernet2/0/0:
110.1.1.1/24
PC1
100.1.1.2/24
PC2
Figure 7-16 Multi-role host networking diagram
III. Configuration procedure
1)
Configure CE1.
# Configure a default route to PE1 on CE1.
[CE1] ip route-static 0.0.0.0 0 1.1.1.1
2)
Configure PE1
# Configure two VPN-instances respectively for VPN1 and VPN2 on PE1, set different
VPN-targets for them.
[PE1] ip vpn-instance vpn1
[PE1-vpn-vpn1] route-distinguisher 100:1
[PE1-vpn-vpn1] vpn-target 100:1 both
[PE1-vpn-vpn1] quit
[PE1] ip vpn-instance vpn2
[PE1-vpn-vpn2] route-distinguisher 100:2
[PE1-vpn-vpn2] vpn-target 100:2 both
[PE1-vpn-vpn2] quit
# Bind the interface connecting PE1 and CE1 with VPN 1.
[PE1] interface ethernet0/0/0
[PE1-Ethernet0/0/0] ip binding vpn-instance vpn1
[PE1-Ethernet0/0/0] ip address 1.1.1.1 255.255.255.0
[PE1-Ethernet0/0/0] quit
# Configure a static route, so that the packets returned from VPN2 can find the correct
route in the VPN-instance vpn1 on PE1 and travel along this route back to PC1.
(Correspondingly, configure MBGP to import the static route on PE2, so that MBGP can
advertise the route among VPN2.)
7-56
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE1] ip route-static vpn-instance vpn2 100.1.0.0 16 vpn-instance vpn1 2.1.1.2
# Configure a policy-based route, so that the packets from PC1 can find a private route
in VPN-instance vpn1 and vpn2 simultaneously and get forwarded.
[PE1] acl number 101
[PE1-acl-adv-101] rule 0 permit ip vpn-instance vpn1 100.1.1.2 0
[PE1-acl-adv-101] quit
[PE1] route-policy aaa permit node 10
[PE1-route-policy] if-match acl 101
[PE1-route-policy] apply access-vpn vpn-instance vpn1 vpn2
[PE1-route-policy] quit
# Enable routing policy at the interface Ethernet0/0/0.
[PE1] interface ethernet0/0/0
[PE1-Ethernet0/0/0] ip policy route-policy aaa
For other settings, refer to the previous example.
7.4.7 OSPF Multi-Instance Sham Link Networking
I. Network requirements
A company is connected to WAN using the OSPF multi-instance function of the firewall,
with OSPF bound to VPN1. Between the PEs is MPLS VPN backbone network. OSPF
runs between the PE and CE. Configure a sham link between PE1 and PE2, so that the
traffic between CE1 and CE2 can bypass the backdoor link directly connected between
them.
II. Network diagram
LoopBack0:
1.1.1.1
CE1
10.10.10.10
E1/0/0
PE1
1.1.1.1
E1/0/0
10.1.1.0/24
E0/0/0
12.1.1.0/24
LoopBack0:
3.3.3.3
PE3
3.3.3.3
E2/0/0
E0/0/0
E0/0/0
MPLS VPN
Backbone
(168.1.1.0/24)
sham link
(backdoor)
LoopBack1
50.1.1.3
LoopBack1: E2/0/0
50.1.1.1
E0/0/0
20.2.1.0/24
E1/0/0
CE2
20.20.20.20
E0/0/0
E1/0/0
E2/0/0
LoopBack1:50.1.1.2
PE2
2.2.2.2
LoopBack0:
2.2.2.2
Figure 7-17 Network diagram for OSPF multi-instance configuration
7-57
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
III. Configuration procedure
1)
Configure PE1
# Enable MPLS and LDP.
[PE1] mpls lsr-id 50.1.1.2
[PE1] mpls
[PE1-mpls] mpls ldp
# Configure vpn-instance.
[PE1] ip vpn-instance VPN1
[PE1-vpn-VPN1] route-distinguisher 2:1
[PE1-vpn-VPN1] vpn-target 100:1 export-extcommunity
[PE1-vpn-VPN1] vpn-target 100:1 import-extcommunity
# Configure interface.
[PE1] interface Ethernet0/0/0
[PE1-Ethernet0/0/0] ip address 168.1.12.1 255.255.255.0
[PE1-Ethernet0/0/0] ospf cost 1
[PE1-Ethernet0/0/0] mpls
[PE1-Ethernet0/0/0] mpls ldp enable
[PE1-Ethernet0/0/0] mpls ldp transport-ip interface
[PE1] interface Ethernet1/0/0
[PE1-Ethernet1/0/0] ip binding vpn-instance VPN1
[PE1-Ethernet1/0/0] ip address 10.1.1.2 255.255.255.0
[PE1-Ethernet1/0/0] ospf cost 1
[PE1] interface Ethernet2/0/0
[PE1-Ethernet2/0/0] ip address 168.1.13.1 255.255.255.0
[PE1-Ethernet2/0/0]ospf cost 1
[PE1-Ethernet2/0/0] mpls
[PE1-Ethernet2/0/0] mpls ldp enable
[PE1-Ethernet2/0/0] mpls ldp transport-ip interface
[PE1] interface loopback0
[PE1-LoopBack0] ip binding vpn-instance VPN1
[PE1-LoopBack0] ip address 1.1.1.1 255.255.255.255
[PE1] interface loopback1
[PE1-LoopBack1] ip address 50.1.1.1 255.255.255.255
# Configure BGP peer.
[PE1] bgp 100
[PE1-bgp] undo synchronization
[PE1-bgp] group fc internal
[PE1-bgp] peer 2.2.2.2 group fc
[PE1-bgp] peer 2.2.2.2 connect-interface LoopBack1
[PE1-bgp] peer 3.3.3.3 group fc
7-58
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE1-bgp] peer 3.3.3.3 connect-interface LoopBack1
# Configure BGP to import OSPF route and direct-connect route.
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-af-vpn-instance] import-route ospf 100
[PE1-bgp-af-vpn-instance] import-route ospf-ase 100
[PE1-bgp-af-vpn-instance] import-route ospf-nssa 100
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn-instance] undo synchronization
# Create peer in MBGP and activate it.
[PE1-bgp-af-vpn] ipv4-family vpnv4
[PE1-bgp-af-vpn] peer fc enable
[PE1-bgp-af-vpn] peer fc advertise-community
[PE1-bgp-af-vpn] peer 2.2.2.2 group fc
[PE1-bgp-af-vpn] peer 3.3.3.3 group fc
# Bind OSPF process to vpn-instance.
[PE1] ospf 100 router-id 1.1.1.1 vpn-instance VPN1
[PE1-ospf-100] import-route bgp
[PE1-ospf-100] area 0.0.0.1
[PE1-ospf-100-area-0.0.0.1] network 10.1.1.0
0.0.0.255
Configure a sham link
[PE1-ospf-100-area-0.0.0.1] sham-link 1.1.1.1 2.2.2.2
# Configure static routes to PE2 and PE3.
[PE1] ip route-static 50.1.1.2 255.255.255.255 168.1.12.2
[PE1] ip route-static 50.1.1.3 255.255.255.255 168.1.13.3
2)
Configure PE2
# Enable MPLS and LDP.
[PE2] mpls lsr-id 50.0.0.1
[PE2] mpls
[PE2- mpls] mpls ldp
# Configure vpn-instance VPN1.
[PE2] ip vpn-instance VPN1
[PE2-vpn-VPN1] route-distinguisher 2:1
[PE2-vpn-VPN1] vpn-target 100:1 export-extcommunity
[PE2-vpn-VPN1] vpn-target 100:1 import-extcommunity
# Configure interface.
[PE2] interface Ethernet0/0/0
[PE2-Ethernet0/0/0] ip address 168.1.12.2 255.255.255.0
[PE2-Ethernet0/0/0] ospf cost 1
7-59
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE2-Ethernet0/0/0] mpls
[PE2-Ethernet0/0/0] mpls ldp enable
[PE2-Ethernet0/0/0] mpls ldp transport-ip interface
[PE2] interface Ethernet1/0/0
[PE2-Ethernet1/0/0] ip binding vpn-instance VPN1
[PE2-Ethernet1/0/0] ip address 20.1.1.2 255.255.255.0
[PE2-Ethernet1/0/0] ospf cost 1
[PE2] interface Ethernet2/0/0
[PE2-Ethernet2/0/0] ip address 168.1.23.2 255.255.255.0
[PE2-Ethernet2/0/0] ospf cost 1
[PE2-Ethernet1/0/0] mpls
[PE2-Ethernet1/0/0] mpls ldp enable
[PE2-Ethernet1/0/0] mpls ldp transport-ip interface
[PE2] interface LoopBack0
[PE2- LoopBack0] ip binding vpn-instance VPN1
[PE2- LoopBack0] ip address 2.2.2.2 255.255.255.255
[PE2] interface LoopBack1
[PE2- LoopBack1] ip address 50.1.1.2 255.255.255.255
# Configure BGP.
[PE2] bgp 100
[PE2-bgp-100] undo synchronization
[PE2-bgp-100] group fc internal
[PE2-bgp-100] peer 50.1.1.1 group fc
[PE2-bgp-100] peer 50.1.1.1 connect-interface LoopBack10
[PE2-bgp-100] peer 50.1.1.3 group fc
[PE2-bgp-100] peer 50.1.1.3 connect-interface LoopBack10
# Configure vpn-instance VPN 1 to import OSPF route and direct-connect route.
[PE2-bgp] ipv4-family vpn-instance VPN1
[PE2-bgp-af-vpn-instance] import-route direct
[PE2-bgp-af-vpn-instance] import-route ospf-nssa 100
[PE2-bgp-af-vpn-instance] import-route ospf-ase 100
[PE2-bgp-af-vpn-instance] import-route ospf 100
[PE2-bgp-af-vpn-instance] undo synchronization
# Configure MBGP to enable peer.
[PE2-bgp-af-vpn] ipv4-family vpnv4
[PE2-bgp-af-vpn] peer fc enable
[PE2-bgp-af-vpn] peer fc advertise-community
[PE2-bgp-af-vpn] peer 50.1.1.1 group fc
[PE2-bgp-af-vpn] peer 50.1.1.3 group fc
# Configure OSPF to import BGP route and direct-connect route.
7-60
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE2] ospf 100 router-id 2.2.2.2 vpn-instance VPN1
[PE2-ospf-100] import-route bgp
[PE2-ospf-100] import-route static
[PE2-ospf-100] area 0.0.0.1
[PE2-ospf-100-0.0.0.1] network 20.1.1.0 0.0.0.255
# Configure a sham link
[PE2-ospf-100-0.0.0.1] sham-link 2.2.2.2 1.1.1.1
# Configure static routes to PE1 and PE3.
[PE2] ip route-static 50.1.1.1 255.255.255.255 168.1.12.1
[PE2] ip route-static 50.1.1.3 255.255.255.255 168.1.23.3
3)
Configure CE1.
# Configure interface.
[CE1] interface Ethernet0/0/0
[CE1-Ethernet0/0/0] ip address 12.1.1.1 255.255.255.0
[CE1-Ethernet0/0/0] ospf cost 1
[CE1] interface Ethernet1/0/0
[CE1-Ethernet1/0/0] ip address 10.1.1.1 255.255.255.0
[CE1-Ethernet1/0/0] ospf cost 1
# Configure OSPF.
[CE1] ospf 100 router-id 10.10.10.129
[CE1-ospf-100] import-route direct
[CE1-ospf-100] area 0.0.0.1
[CE1-ospf-100] network 10.1.1.0 0.0.0.255
[CE1-ospf-100] network 12.1.1.0 0.0.0.255
4)
Configure E2
# Configure interface.
[CE2] interface Ethernet0/0/0
[CE2-Ethernet0/0/0] ip address 12.1.1.2 255.255.255.0
[CE2-Ethernet0/0/0] ospf cost 1
[CE2] interface Ethernet1/0/0
[CE2-Ethernet1/0/0] ip address 20.1.1.1 255.255.255.0
[CE2-Ethernet1/0/0] ospf cost 1
# Configure OSPF.
[CE2] ospf 100 router-id 20.20.20.20
[CE2-ospf-100] area 0.0.0.1
[CE2-ospf-100] network 12.1.1.0 0.0.0.255
[CE2-ospf-100] network 20.1.1.0 0.0.0.255
7-61
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
7.4.8 OSPF Multi-Instance CE Networking
I. Network requirements
Configure multiple vpn-instances to isolate the services between multiple CEs in a
VPN.
II. Network diagram
vpn1
ospf 100
vpn2
E0/0/0
E1/0/0
MPLS
Network
PE
ospf 300 E2/0/0
E3/0/0
vpn2
Multi-VPNInstance CE
vpn2
Figure 7-18 Network diagram of OSPF multi-instance CE configuration
III. Configuration procedure
# Configure CE
# Configure instance CE-VPN1
[CE] ip vpn-instance CE-VPN1
[CE-vpn-CE-VPN1] route-distinguisher 100:1
[CE-vpn-CE-VPN1] vpn-target 100:1 export-extcommunity
[CE-vpn-CE-VPN1] vpn-target 100:1 import-extcommunity
# Configure instance CE-VPN2
[CE] ip vpn-instance CE-VPN2
[CE-vpn-CE-VPN2] route-distinguisher 200:1
[CE-vpn-CE-VPN2] vpn-target 200:1 export-extcommunity
[CE-vpn-CE-VPN2] vpn-target 200:1 import-extcommunity
# Configure ethernet0/0/0
[CE] interface Ethernet0/0/0
[CE-Ethernet 0/0/0] ip binding vpn-instance CE-VPN1
[CE-Ethernet 0/0/0] ip address 10.1.1.2 255.255.255.0
# Configure ethernet1/0/0
[CE] interface Ethernet1/0/0
[CE-Ethernet1/0/0] ip binding vpn-instance CE-VPN1
[CE-Ethernet1/0/0] ip address 10.2.1.2 255.255.255.0
[CE-Ethernet1/0/0] ospf cost 100
# Configure ethernet2/0/0
7-62
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[CE] interface Ethernet2/0/0
[CE-Ethernet2/0/0] ip binding vpn-instance CE-VPN2
[CE-Ethernet2/0/0] ip address 20.1.1.2 255.255.255.0
# Configure ethernet3/0/0
[CE] interface Ethernet3/0/0
[CE-Ethernet3/0/0] ip binding vpn-instance CE-VPN2
[CE-Ethernet3/0/0] ip address 20.2.1.2 255.255.255.0
# Configure ospf 100
[CE] ospf 100 vpn-instance CE-VPN1
[CE-ospf-100] vpn-instance-capability simple
[CE-ospf-100] area 0.0.0.0
[CE-ospf-100-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[CE-ospf-100-area-0.0.0.0] network 10.2.1.0 0.0.0.255
# Configure ospf 200
[CE] ospf 200 vpn-instance CE-VPN2
[CE-ospf-200] vpn-instance-capability simple
[CE-ospf-200] area 0.0.0.1
[CE-ospf-100-area-0.0.0.1] network 20.1.1.0 0.0.0.255
[CE-ospf-100-area-0.0.0.1] network 20.2.1.0 0.0.0.255
7.4.9 Configuring Inter-Provider Backbones Option A
I. Network requirements
CE1 and CE2 belong to the same VPN. CE1 accesses the network through PE1 in AS
100 and CE2 accesses the network through PE2 in AS 200.
Multi-AS BGP/MPLS VPN is implemented using Option A method. (That is,
VPN-INSTANCE-to-VPN-INSTANCE method is used to manage VPN routes).
The MPLS backbone network in the same AS adopts OSPF as the IGP.
7-63
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
II. Network diagram
BGP/MPLS Backbone
AS 200
BGP/MPLS Backbone
AS 100
Loopback0:
202.100.1.1/32
Loopback0:
202.200.1.1/32
E2/0/0:
E2/0/0:
E1/0/0:
E1/0/0:
192.1.1.1/24192.1.1.2/24
162.1.1.1/16 Loopback0:
Loopback0: 172.1.1.1/16
202.100.1.2/32
200.200.1.2/32
ASBR -PE1
ASBR-PE2
LSR ID:172.1.1.1
LSR ID:162.1.1.1
E1/0/0:
E1/0/0:
172.1.1.2/16
162.1.1.2/16
PE1
PE2
LSR ID:
Ethernet2/0/0: LSR ID:
Ethernet2/0/0:
172.1.1.2
168.2.2.1/16 162.1.1.2
168.1.1.1/16
Ethernet1:
Ethernet1:
168.1.1.2/16
168.2.2.2/16
CE2
AS 65002
CE1
AS 65001
Figure 7-19 Network diagram for Inter-Provider Backbones
III. Configuration procedure
The configuration procedures include:
z
Configuring OSPF on the MPLS backbone network
z
Configuring basic MPLS capability on the MPLS backbone network
z
Configuring VPN instances on PEs
z
Configuring MP-BGP
They are introduced below in order.
1)
Configuring OSPF on the MPLS backbone network to make PEs learn routes from
each other
# Configure PE1.
[PE1] interface loopback0
[PE1-LoopBack0] ip address 202.100.1.2 255.255.255.255
[PE1-LoopBack0] quit
[PE1] interface Ethernet1/0/0
[PE1-Ethernet1/0/0] ip address 172.1.1.2 255.255.0.0
[PE1-Ethernet1/0/0] quit
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 172.1.0.0 0.0.255.255
[PE1-ospf-1-area-0.0.0.0] network 202.100.1.2 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
# Configure ASBR-PE1.
7-64
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[ASBR-PE1] interface loopback0
[ASBR-PE1-LoopBack 0] ip address 202.100.1.1 255.255.255.255
[ASBR-PE1-LoopBack 0] quit
[ASBR-PE1] interface Ethernet1/0/0
[ASBR-PE1-Ethernet1/0/0] ip address 172.1.1.1 255.255.0.0
[ASBR-PE1-Ethernet1/0/0] quit
[ASBR-PE1] ospf
[ASBR-PE1-ospf-1] area 0
[ASBR-PE1-ospf-1-area-0.0.0.0] network 172.1.0.0 0.0.255.255
[ASBR-PE1-ospf-1-area-0.0.0.0] network 202.100.1.1 0.0.0.0
[ASBR-PE1-ospf-1-area-0.0.0.0] quit
[ASBR-PE1-ospf-1] quit
# Configure PE2.
[PE2] interface loopback0
[PE2-LoopBack0] ip address 202.200.1.2 255.255.255.255
[PE2-LoopBack0] quit
[PE2] interface Ethernet1/0/0
[PE2-Ethernet1/0/0] ip address 162.1.1.2 255.255.0.0
[PE2-Ethernet1/0/0] quit
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1-area-0.0.0.0] network 162.1.0.0 0.0.255.255
[PE2-ospf-1-area-0.0.0.0] network 202.200.1.2 0.0.0.0
[PE2-ospf-1-area-0.0.0.0] quit
[PE2-ospf-1] quit
# Configure ASBR-PE2.
[ASBR-PE2] interface loopback0
[ASBR-PE2-LoopBack0] ip address 202.200.1.1 255.255.255.255
[ASBR-PE2-LoopBack0] quit
[ASBR-PE2] interface Ethernet1/0/0
[ASBR-PE2-Ethernet1/0/0] ip address 162.1.1.1 255.255.0.0
[ASBR-PE2-Ethernet1/0/0] quit
[ASBR-PE2] ospf
[ASBR-PE2-ospf-1] area 0
[ASBR-PE2-ospf-1-area-0.0.0.0] network 162.1.0.0 0.0.255.255
[ASBR-PE2-ospf-1-area-0.0.0.0] network 202.200.1.1 0.0.0.0
[ASBR-PE2-ospf-1-area-0.0.0.0] quit
[ASBR-PE2-ospf-1] quit
After the configuration, the OSPF neighbor relationship should be established between
ASBR PE and the PEs of the same AS. Executing the display ospf peer command,
7-65
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
you can find that the OSPF neighbor relationship is in Full state. PEs can learn
Loopback addresses from each other.
The ping operation succeeds between ASBR-PE and other PEs in the same AS.
Take PE1 and ASBR-PE1 as an example:
[PE1] display ospf peer
OSPF Process 1 with Router ID 202.100.1.2
Neighbors
Area 0 interface 172.1.1.2(Ethernet1/0/0)'s neighbor(s)
RouterID: 202.100.1.1
State: Full
DR: None
Address: 172.1.1.1
Mode: Nbr is Slave
Priority: 1
BDR: None
Dead timer expires in 40s
Neighbor comes up for 00:01:32
[PE1] display ip routing-table
Routing Table: public net
Destination/Mask
Protocol Pre
Cost
Nexthop
Interface
127.0.0.0/8
DIRECT
0
0
127.0.0.1
InLoopBack0
127.0.0.1/32
DIRECT
0
0
127.0.0.1
InLoopBack0
172.1.0.0/16
DIRECT
0
0
172.1.1.2
Ethernet1/0/0
172.1.1.1/32
DIRECT
0
0
172.1.1.1
Ethernet1/0/0
172.1.1.2/32
DIRECT
0
0
127.0.0.1
InLoopBack0
202.100.1.1/32
OSPF
10
1563
172.1.1.1
Ethernet1/0/0
202.100.1.2/32
DIRECT
0
0
127.0.0.1
InLoopBack0
[PE1] ping 202.100.1.1
PING 202.100.1.1: 56
data bytes, press CTRL_C to break
Reply from 202.100.1.1: bytes=56 Sequence=1 ttl=255 time=10 ms
Reply from 202.100.1.1: bytes=56 Sequence=2 ttl=255 time=1 ms
Reply from 202.100.1.1: bytes=56 Sequence=3 ttl=255 time=50 ms
Reply from 202.100.1.1: bytes=56 Sequence=4 ttl=255 time=80 ms
Reply from 202.100.1.1: bytes=56 Sequence=5 ttl=255 time=1 ms
--- 202.100.1.1 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/28/80 ms
[ASBR-PE1] display ospf peer
OSPF Process 1 with Router ID 202.100.1.1
Neighbors
Area 0 interface 172.1.1.1(Ethernet1/0/0)'s neighbor(s)
7-66
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
RouterID: 202.100.1.2
State: Full
DR: None
Address: 172.1.1.2
Mode: Nbr is Master
Priority: 1
BDR: None
Dead timer expires in 30s
Neighbor comes up for 00:01:49
[ASBR-PE1] display ip routing-table
Routing Table: public net
Destination/Mask
Protocol Pre
Cost
Nexthop
Interface
127.0.0.0/8
DIRECT
0
0
127.0.0.1
InLoopBack0
127.0.0.1/32
DIRECT
0
0
127.0.0.1
InLoopBack0
172.1.0.0/16
DIRECT
0
0
172.1.1.1
Ethernet1/0/0
172.1.1.1/32
DIRECT
0
0
127.0.0.1
InLoopBack0
172.1.1.2/32
DIRECT
0
0
172.1.1.2
Ethernet1/0/0
202.100.1.1/32
DIRECT
0
0
127.0.0.1
InLoopBack0
202.100.1.2/32
OSPF
10
1563
172.1.1.2
Ethernet1/0/0
[ASBR-PE1] ping 202.100.1.2
PING 202.100.1.2: 56
data bytes, press CTRL_C to break
Reply from 202.100.1.2: bytes=56 Sequence=1 ttl=255 time=10 ms
Reply from 202.100.1.2: bytes=56 Sequence=2 ttl=255 time=10 ms
Reply from 202.100.1.2: bytes=56 Sequence=3 ttl=255 time=10 ms
Reply from 202.100.1.2: bytes=56 Sequence=4 ttl=255 time=60 ms
Reply from 202.100.1.2: bytes=56 Sequence=5 ttl=255 time=10 ms
--- 202.100.1.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 10/20/60 ms
2)
Configuring basic MPLS capability on the MPLS backbone network to make the
network forward VPN traffic
# Configure basic MPLS capability on PE1 and enable LDP on the interface connecting
ASBR-PE1.
[PE1] mpls lsr-id 172.1.1.2
[PE1] mpls
[PE1-mpls] lsp-trigger all
[PE1-mpls] quit
[PE1] mpls ldp
[PE1] interface Ethernet1/0/0
[PE1-Ethernet1/0/0] mpls
[PE1-Ethernet1/0/0] mpls ldp enable
[PE1-Ethernet1/0/0] quit
7-67
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
# Configure basic MPLS capability on ASBR-PE1 and enable LDP on the interface
connecting PE1.
[ASBR-PE1] mpls lsr-id 172.1.1.1
[ASBR-PE1] mpls
[ASBR-PE1-mpls] lsp-trigger all
[ASBR-PE1-mpls] quit
[ASBR-PE1] mpls ldp
[ASBR-PE1] interface Ethernet1/0/0
[ASBR-PE1-Ethernet1/0/0] mpls
[ASBR-PE1-Ethernet1/0/0] mpls ldp enable
[ASBR-PE1-Ethernet1/0/0] quit
# Configure basic MPLS capability on ASBR-PE2 and enable LDP on the interface
connecting PE2.
[ASBR-PE2] mpls lsr-id 162.1.1.1
[ASBR-PE2] mpls
[ASBR-PE2-mpls] lsp-trigger all
[ASBR-PE2-mpls] quit
[ASBR-PE2] mpls ldp
[ASBR-PE2] interface Ethernet1/0/0
[ASBR-PE2-Ethernet1/0/0] mpls
[ASBR-PE2-Ethernet1/0/0] mpls ldp enable
[ASBR-PE2-Ethernet1/0/0] quit
# Configure basic MPLS capability on PE2 and enable LDP on the interface connecting
ASBR-PE2.
[PE2] mpls lsr-id 162.1.1.2
[PE2] mpls
[PE2-mpls] lsp-trigger all
[PE2-mpls] quit
[PE2] mpls ldp
[PE2] interface Ethernet1/0/0
[PE2-Ethernet1/0/0] mpls
[PE2-Ethernet1/0/0] mpls ldp enable
[PE2-Ethernet1/0/0] quit
After you complete the configurations, the PEs and the ASBR-PEs in the same AS
should be able to set up LDP neighborhood. Executing the display mpls ldp session
command on the firewalls, you can find the Session State is “Operational” in the output.
You do not need to enable MPLS on the interface connecting ASBR-PE1 and
ASBR-PE2.
Take the display results on PE1 and ASBR-PE1 for example:
[PE1] display mpls ldp session
7-68
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Displaying information about all sessions:
Local LDP ID: 172.1.1.2:0;
Peer LDP ID: 172.1.1.1:0
TCP Connection: 172.1.1.2 -> 172.1.1.1
Session State: Operational
Session Role: Active
Session existed time: 3 minutes 32 seconds
KeepAlive Packets Sent/Received: 11/11
Negotiated Keepalive hold time: 60
Peer PV Limit: 0
LDP Basic Discovery Source((A) means active):
Ethernet1/0/0(A)
[ASBR-PE1] display mpls ldp session
Displaying information about all sessions:
Local LDP ID: 172.1.1.1:0;
Peer LDP ID: 172.1.1.2:0
TCP Connection: 172.1.1.1 <- 172.1.1.2
Session State: Operational
Session Role: Passive
Session existed time: 4 minutes 37 seconds
KeepAlive Packets Sent/Received: 14/14
Negotiated Keepalive hold time: 60
Peer PV Limit: 0
LDP Basic Discovery Source((A) means active):
Ethernet1/0/0(A)
3)
Configuring VPN instances on PEs and binding to the interfaces connecting to
CEs
Note:
The VPN-Target attributes of VPN instances of ASBR-PE and PE in the same AS
should match each other. In different ASs, the matching of VPN-Target attributes of
PEs is unnecessary.
# Configure CE1.
[CE1] interface ethernet 1
[CE1-Ethernet1] ip address 168.1.1.2 255.255.0.0
[CE1-Ethernet1] quit
# Configure a VPN instance on PE1 and bind it to the interface connecting to CE1.
[PE1] ip vpn-instance vpna
[PE1-vpn-vpn-vpna] route-distinguisher 100:2
[PE1-vpn-vpn-vpna] vpn-target 100:1 both
[PE1-vpn-vpn-vpna] quit
7-69
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE1] interface ethernet 2/0/0
[PE1-Ethernet2/0/0] ip binding vpn-instance vpna
[PE1-Ethernet2/0/0] ip address 168.1.1.1 255.255.0.0
[PE1-Ethernet2/0/0] quit
# Configure a VPN instance on ASBR-PE1 and bind it to the interface connecting to
ASBR-PE2 (ASBR-PE1 regards ASBR-PE2 as its CE).
[ASBR-PE1] ip vpn-instance vpna
[ASBR-PE1-vpn-vpn-vpna] route-distinguisher 100:1
[ASBR-PE1-vpn-vpn-vpna] vpn-target 100:1 both
[ASBR-PE1-vpn-vpn-vpna] quit
[ASBR-PE1] interface Ethernet 2/0/0
[ASBR-PE1-Ethernet2/0/0] ip binding vpn-instance vpna
[ASBR-PE1-Ethernet2/0/0] ip address 192.1.1.1 255.255.255.0
[ASBR-PE1-Ethernet2/0/0] quit
# Configure CE2.
[CE2] interface ethernet 1
[CE2-Ethernet1] ip address 168.2.2.2 255.255.0.0
[CE2-Ethernet1] quit
# Configure a VPN instance on PE2 and bind it to the interface connecting to CE2.
[PE2] ip vpn-instance vpna
[PE2-vpn-instance] route-distinguisher 200:2
[PE2-vpn-instance] vpn-target 100:1 both
[PE2-vpn-instance] quit
[PE2] interface ethernet 2/0/0
[PE2-Ethernet2/0/0] ip binding vpn-instance vpna
[PE2-Ethernet2/0/0] ip address 168.2.2.1 255.255.0.0
[PE2-Ethernet2/0/0] quit
# Configure a VPN instance on ASBR-PE2 and bind it to the interface connecting to
ASBR-PE1 (ASBR-PE2 regards ASBR-PE1 as its CE).
[ASBR-PE2] ip vpn-instance vpna
[ASBR-PE2-vpn-vpn-vpna] route-distinguisher 200:1
[ASBR-PE2-vpn-vpn-vpna] vpn-target 100:1 both
[ASBR-PE2-vpn-vpn-vpna] quit
[ASBR-PE2] interface Ethernet 2/0/0
[ASBR-PE2-Ethernet2/0/0] ip binding vpn-instance vpna
[ASBR-PE2-Ethernet2/0/0] ip address 192.1.1.2 255.255.255.0
[ASBR-PE2-Ethernet2/0/0] quit
After the configuration, you can see the VPN instance configuration by executing the
display ip vpn-instance verbose command on PEs.
Take the display results on PE1 and ASBR-PE1 as an example:
7-70
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE1] display ip vpn-instance verbose
VPN-Instance : vpna
No description
Route-Distinguisher :
100:2
Interfaces :
Ethernet2/0/0
Export-ext-communities :
100:1
Import-ext-communities :
100:1
[ASBR-PE1] display ip vpn-instance verbose
VPN-Instance : vpna
No description
Route-Distinguisher :
100:1
Interfaces :
Ethernet2/0/0
Export-ext-communities :
100:1
Import-ext-communities :
100:1
The ping operations are successful to CEs on PEs, and successful between
ASBR-PEs.
When pinging CE on PE, you need to specify the VPN to which the destination address
belongs.
For example, ping ASBR-PE2 on ASBR-PE1:
[ASBR-PE1] ping -vpn-instance vpna 192.1.1.2
PING 192.1.1.2: 56
data bytes, press CTRL_C to break
Reply from 192.1.1.2: bytes=56 Sequence=1 ttl=255 time=10 ms
Reply from 192.1.1.2: bytes=56 Sequence=2 ttl=255 time=10 ms
Reply from 192.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 ms
Reply from 192.1.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms
Reply from 192.1.1.2: bytes=56 Sequence=5 ttl=255 time=60 ms
--- 192.1.1.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/16/60 ms
Ping PE1 on CE1:
7-71
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[CE1] ping 168.1.1.1
PING 168.1.1.1: 56
data bytes, press CTRL_C to break
Reply from 168.1.1.1: bytes=56 Sequence=1 ttl=255 time=1 ms
Reply from 168.1.1.1: bytes=56 Sequence=2 ttl=255 time=60 ms
Reply from 168.1.1.1: bytes=56 Sequence=3 ttl=255 time=1 ms
Reply from 168.1.1.1: bytes=56 Sequence=4 ttl=255 time=60 ms
Reply from 168.1.1.1: bytes=56 Sequence=5 ttl=255 time=10 ms
--- 168.1.1.1 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/26/60 ms
Ping CE1 on PE1:
[PE1] ping -vpn-instance vpna 168.1.1.2
PING 168.1.1.2: 56
data bytes, press CTRL_C to break
Reply from 168.1.1.2: bytes=56 Sequence=1 ttl=255 time=10 ms
Reply from 168.1.1.2: bytes=56 Sequence=2 ttl=255 time=10 ms
Reply from 168.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 ms
Reply from 168.1.1.2: bytes=56 Sequence=4 ttl=255 time=50 ms
Reply from 168.1.1.2: bytes=56 Sequence=5 ttl=255 time=10 ms
--- 168.1.1.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/16/50 ms
4)
Configuring MP-BGP, establishing IBGP peer relationship between PEs, and
establishing EBGP peer relationship between PE and CE
# Configure CE1.
[CE1] bgp 65001
[CE1-bgp] group 20 external
[CE1-bgp] peer 168.1.1.1 group 20 as-number 100
[CE1-bgp] quit
# Configure PE1 to establish EBGP peer relationship with CE1 and IBGP peer
relationship with ASBR-PE1.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpna
[PE1-bgp-af-vpn-instance] group 10 external
[PE1-bgp-af-vpn-instance] peer 168.1.1.2 group 10 as-number 65001
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn-instance] quit
[PE1-bgp] group 20
7-72
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE1-bgp] peer 202.100.1.1 group 20
[PE1-bgp] peer 202.100.1.1 connect-interface loopback0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpn] peer 20 enable
[PE1-bgp-af-vpn] peer 202.100.1.1 group 20
[PE1-bgp-af-vpn] quit
[PE1-bgp] quit
# Configure ASBR-PE1 to establish EBGP peer relationship with ASBR-PE2 and IBGP
peer relationship with PE1.
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] ipv4-family vpn-instance vpna
[ASBR-PE1-bgp-af-vpn-instance] group 10 external
[ASBR-PE1-bgp-af-vpn-instance] peer 192.1.1.2 group 10 as-number 200
[ASBR-PE1-bgp-af-vpn-instance] quit
[ASBR-PE1-bgp] group 20
[ASBR-PE1-bgp] peer 202.100.1.2 group 20
[ASBR-PE1-bgp] peer 202.100.1.2 connect-interface loopback0
[ASBR-PE1-bgp] ipv4-family vpnv4
[ASBR-PE1-bgp-af-vpn] peer 20 enable
[ASBR-PE1-bgp-af-vpn] peer 202.100.1.2 group 20
[ASBR-PE1-bgp-af-vpn] quit
[ASBR-PE1-bgp] quit
# Configure CE2.
[CE2] bgp 65002
[CE2-bgp] group 10 external
[CE2-bgp] peer 168.2.2.1 group 10 as-number 200
[CE2-bgp] quit
# Configure PE2 to establish EBGP peer relationship with CE2 and IBGP peer
relationship with ASBR-PE2.
[PE2] bgp 200
[PE2-bgp] ipv4-family vpn-instance vpna
[PE2-bgp-af-vpn-instance] group 10 external
[PE2-bgp-af-vpn-instance] peer 168.2.2.2 group 10 as-number 65002
[PE2-bgp-af-vpn-instance] import-route direct
[PE2-bgp-af-vpn-instance] quit
[PE2-bgp] group 20
[PE2-bgp] peer 202.200.1.1 group 20
[PE2-bgp] peer 202.200.1.1 connect-interface loopback0
[PE2-bgp] ipv4-family vpnv4
[PE2-bgp-af-vpn] peer 20 enable
[PE2-bgp-af-vpn] peer 202.200.1.1 group 20
7-73
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE2-bgp-af-vpn] quit
[PE2-bgp] quit
# Configure ASBR-PE2 to establish EBGP peer relationship with ASBR-PE1 and IBGP
peer relationship with PE2.
[ASBR-PE2] bgp 200
[ASBR-PE2-bgp] ipv4-family vpn-instance vpna
[ASBR-PE2-bgp-af-vpn-instance] group 10 external
[ASBR-PE2-bgp-af-vpn-instance] peer 192.1.1.1 group 10 as-number 100
[ASBR-PE2-bgp-af-vpn-instance] quit
[ASBR-PE2-bgp] group 20
[ASBR-PE2-bgp] peer 202.200.1.2 group 20
[ASBR-PE2-bgp] peer 202.200.1.2 connect-interface loopback0
[ASBR-PE2-bgp] ipv4-family vpnv4
[ASBR-PE2-bgp-af-vpn] peer 20 enable
[ASBR-PE2-bgp-af-vpn] peer 202.200.1.2 group 20
[ASBR-PE2-bgp-af-vpn] quit
[ASBR-PE2-bgp] quit
After the configuration, you can find that the BGP peer relationship has been
established in Established state between PEs and between PE and CE.
Take the display results on PE1 and ASBR-PE1 as an example:
[PE1] display bgp vpnv4 all peer
Peer
AS-num Ver Queued-Tx
Msg-Rx
Msg-Tx
Up/Down
State
-------------------------------------------------------------------168.1.1.2
65001
4
0
4
7
00:03:23 Established
100
4
0
1
1
00:03:14 Established
202.100.1.1
[ASBR-PE1] display bgp vpnv4 all peer
Peer
AS-num Ver Queued-Tx
Msg-Rx
Msg-Tx
Up/Down
State
-------------------------------------------------------------------192.1.1.2
200
4
0
5
6
00:03:38 Established
202.100.1.2
100
4
0
1
1
00:04:17 Established
CEs can learn interface routes from each other. CE1 and CE2 can be pinged
successfully on each other.
[CE1] display ip routing-table
Routing Table: public net
Destination/Mask
Protocol Pre
Cost
Nexthop
Interface
127.0.0.0/8
DIRECT
0
0
127.0.0.1
InLoopBack0
127.0.0.1/32
DIRECT
0
0
127.0.0.1
InLoopBack0
168.1.0.0/16
DIRECT
0
0
168.1.1.2
Ethernet1
168.1.1.2/32
DIRECT
0
0
127.0.0.1
InLoopBack0
7-74
Operation Manual – VPN
H3C SecPath Series Security Products
168.2.0.0/16
Chapter 7 BGP/MPLS VPN Configuration
BGP
256
0
168.1.1.1
Ethernet2/0/0
[PE1] display ip routing-table vpn-instance vpna
vpna
Route Information
Routing Table:
vpna
Route-Distinguisher:
100:2
Destination/Mask
Protocol Pre
Cost
Nexthop
Interface
168.1.0.0/16
DIRECT
0
0
168.1.1.1
Ethernet2/0/0
168.1.1.1/32
DIRECT
0
0
127.0.0.1
InLoopBack0
VPN Routing Table:
168.2.0.0/16
Route-Distinguisher:
BGP
256
0
100:1
202.100.1.1
InLoopBack0
[ASBR-PE1] display ip routing-table vpn-instance vpna
vpna
Route Information
Routing Table:
vpna
Route-Distinguisher:
100:1
Destination/Mask
Protocol Pre
Cost
Nexthop
Interface
168.2.0.0/16
BGP
256
0
192.1.1.2
Ethernet2/0/0
192.1.1.0/24
DIRECT
0
0
192.1.1.1
Ethernet2/0/0
192.1.1.1/32
DIRECT
0
0
127.0.0.1
InLoopBack0
192.1.1.2/32
DIRECT
0
0
192.1.1.2
Ethernet2/0/0
VPN Routing Table:
168.1.0.0/16
Route-Distinguisher:
BGP
256
0
100:2
202.100.1.2
InLoopBack0
[CE1] ping 168.2.2.2
PING 168.2.2.2: 56
data bytes, press CTRL_C to break
Reply from 168.2.2.2: bytes=56 Sequence=1 ttl=251 time=140 ms
Reply from 168.2.2.2: bytes=56 Sequence=2 ttl=251 time=130 ms
Reply from 168.2.2.2: bytes=56 Sequence=3 ttl=251 time=130 ms
Reply from 168.2.2.2: bytes=56 Sequence=4 ttl=251 time=70 ms
Reply from 168.2.2.2: bytes=56 Sequence=5 ttl=251 time=130 ms
--- 168.2.2.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 70/120/140 ms
[CE2] ping 168.1.1.2
PING 168.1.1.2: 56
data bytes, press CTRL_C to break
Reply from 168.1.1.2: bytes=56 Sequence=1 ttl=251 time=130 ms
Reply from 168.1.1.2: bytes=56 Sequence=2 ttl=251 time=190 ms
Reply from 168.1.1.2: bytes=56 Sequence=3 ttl=251 time=70 ms
Reply from 168.1.1.2: bytes=56 Sequence=4 ttl=251 time=130 ms
Reply from 168.1.1.2: bytes=56 Sequence=5 ttl=251 time=190 ms
--- 168.1.1.2 ping statistics ---
7-75
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 70/142/190 ms
7.4.10 Configuring Inter-Provider Backbones Option B
I. Network requirements
CE1 and CE2 belong to the same VPN. CE1 accesses the network through PE1 in AS
100 and CE2 accesses the network through PE2 in AS 200.
Multi-AS BGP/MPLS VPN is implemented through Option B method. That is, VPN-IPv4
routes are advertised between ASBRs.
The MPLS backbone network in the same AS adopts OSPF as the IGP.
II. Network diagram
See Figure 7-19.
III. Configuration procedure
The configuration procedures include:
z
Configuring OSPF on the MPLS backbone network
z
Configuring basic MPLS capability on the MPLS backbone network
z
Configuring VPN instances on PEs
z
Configuring MP-BGP
Compared with Option A, Option B differs in the last two procedures.
1)
Configuring OSPF on the MPLS backbone network to make PEs learn routes from
each other
Note:
In this part:
z
The configurations on PE1 and PE2 are the same as those in section 7.4.9
“Configuring Inter-Provider Backbones Option A”.
z
Configuration of interface IP address between ASBR-PE1 and ASBR-PE2 is added.
# Configure PE1.
[PE1] interface loopback0
[PE1-LoopBack0] ip address 202.100.1.2 255.255.255.255
[PE1-LoopBack0] quit
[PE1] interface Ethernet1/0/0
[PE1-Ethernet1/0/0] ip address 172.1.1.2 255.255.0.0
7-76
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE1-Ethernet1/0/0] quit
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 172.1.0.0 0.0.255.255
[PE1-ospf-1-area-0.0.0.0] network 202.100.1.2 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
# Configure ASBR-PE1.
[ASBR-PE1] interface loopback0
[ASBR-PE1-LoopBack 0] ip address 202.100.1.1 255.255.255.255
[ASBR-PE1-LoopBack 0] quit
[ASBR-PE1] interface Ethernet1/0/0
[ASBR-PE1-Ethernet1/0/0] ip address 172.1.1.1 255.255.0.0
[ASBR-PE1-Ethernet1/0/0] quit
[ASBR-PE1] interface Ethernet 2/0/0
[ASBR-PE1-Ethernet2/0/0] ip address 192.1.1.1 255.255.255.0
[ASBR-PE1-Ethernet2/0/0] quit
[ASBR-PE1] ospf
[ASBR-PE1-ospf-1] area 0
[ASBR-PE1-ospf-1-area-0.0.0.0] network 172.1.0.0 0.0.255.255
[ASBR-PE1-ospf-1-area-0.0.0.0] network 202.100.1.1 0.0.0.0
[ASBR-PE1-ospf-1-area-0.0.0.0] quit
[ASBR-PE1-ospf-1] quit
# Configure PE2.
[PE2] interface loopback0
[PE2-LoopBack0] ip address 202.200.1.2 255.255.255.255
[PE2-LoopBack0] quit
[PE2] interface Ethernet1/0/0
[PE2-Ethernet1/0/0] ip address 162.1.1.2 255.255.0.0
[PE2-Ethernet1/0/0] quit
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1-area-0.0.0.0] network 162.1.0.0 0.0.255.255
[PE2-ospf-1-area-0.0.0.0] network 202.200.1.2 0.0.0.0
[PE2-ospf-1-area-0.0.0.0] quit
[PE2-ospf-1] quit
# Configure ASBR-PE2.
[ASBR-PE2] interface loopback0
[ASBR-PE2-LoopBack0] ip address 202.200.1.1 255.255.255.255
[ASBR-PE2-LoopBack0] quit
[ASBR-PE2] interface Ethernet1/0/0
7-77
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[ASBR-PE2-Ethernet1/0/0] ip address 162.1.1.1 255.255.0.0
[ASBR-PE2-Ethernet1/0/0] quit
[ASBR-PE2] interface Ethernet 2/0/0
[ASBR-PE2-Ethernet2/0/0] ip address 192.1.1.2 255.255.255.0
[ASBR-PE2-Ethernet2/0/0] quit
[ASBR-PE2] ospf
[ASBR-PE2-ospf-1] area 0
[ASBR-PE2-ospf-1-area-0.0.0.0] network 162.1.0.0 0.0.255.255
[ASBR-PE2-ospf-1-area-0.0.0.0] network 202.200.1.1 0.0.0.0
[ASBR-PE2-ospf-1-area-0.0.0.0] quit
[ASBR-PE2-ospf-1] quit
After the configuration, the OSPF neighbor relationship should be established between
ASBR PE and PEs in the same AS. Executing the display ospf peer command, you
can find that the neighbor relationship is in Full state. PEs can learn Loopback
addresses from each other.
ASBR-PE and other PEs in the same AS can be pinged successfully on each other.
ASBR-PEs can be pinged successfully on each other.
2)
Configuring basic MPLS capability on the MPLS backbone network to make the
network forward VPN traffic
Note:
In this part:
The configurations on PE1, PE2, ASBR-PE1, and ASBR-PE2 are the same as those in
section 7.4.9 “Configuring Inter-Provider Backbones Option A”.
# Configure basic MPLS capability on PE1 and enable LDP on the interface connecting
ASBR-PE1.
[PE1] mpls lsr-id 172.1.1.2
[PE1] mpls
[PE1-mpls] lsp-trigger all
[PE1-mpls] quit
[PE1] mpls ldp
[PE1] interface Ethernet1/0/0
[PE1-Ethernet1/0/0] mpls
[PE1-Ethernet1/0/0] mpls ldp enable
[PE1-Ethernet1/0/0] quit
# Configure basic MPLS capability on ASBR-PE1 and enable LDP on the interface
connecting PE1.
[ASBR-PE1] mpls lsr-id 172.1.1.1
7-78
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[ASBR-PE1] mpls
[ASBR-PE1-mpls] lsp-trigger all
[ASBR-PE1-mpls] quit
[ASBR-PE1] mpls ldp
[ASBR-PE1] interface Ethernet1/0/0
[ASBR-PE1-Ethernet1/0/0] mpls
[ASBR-PE1-Ethernet1/0/0] mpls ldp enable
[ASBR-PE1-Ethernet1/0/0] quit
# Configure basic MPLS capability on ASBR-PE2 and enable LDP on the interface
connecting PE2.
[ASBR-PE2] mpls lsr-id 162.1.1.1
[ASBR-PE2] mpls
[ASBR-PE2-mpls] lsp-trigger all
[ASBR-PE2-mpls] quit
[ASBR-PE2] mpls ldp
[ASBR-PE2] interface Ethernet1/0/0
[ASBR-PE2-Ethernet1/0/0] mpls
[ASBR-PE2-Ethernet1/0/0] mpls ldp enable
[ASBR-PE2-Ethernet1/0/0] quit
# Configure basic MPLS capability on PE2 and enable LDP on the interface connecting
ASBR-PE2.
[PE2] mpls lsr-id 162.1.1.2
[PE2] mpls
[PE2-mpls] lsp-trigger all
[PE2-mpls] quit
[PE2] mpls ldp
[PE2] interface Ethernet1/0/0
[PE2-Ethernet1/0/0] mpls
[PE2-Ethernet1/0/0] mpls ldp enable
[PE2-Ethernet1/0/0] quit
After the configuration, the LDP neighbor relationship should be established between
PE and ASBR-PE in the same AS. Executing the display mpls ldp session command
on the firewalls, you can find the Session State item is “Operational” in the display
result.
3)
Configuring VPN instances on PEs and binding to the interfaces connecting to
CEs
7-79
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Note:
Different from Option A, Option B method requires that the VPN-Target attribute of VPN
instances of ASBR-PE and PE in the same AS should match each other. In addition, in
different ASs, the matching of VPN-Target attributes of PEs is necessary.
In this part:
z
The configurations on CE1, CE2, PE1, and PE2 are the same as those in section
7.4.9 “Configuring Inter-Provider Backbones Option A”.
z
It is unnecessary to configure VPN instances and interface binding on ASBR-PEs.
# Configure CE1.
[CE1] interface ethernet 1
[CE1-Ethernet1] ip address 168.1.1.2 255.255.0.0
[CE1-Ethernet1] quit
# Configure a VPN instance on PE1 and bind it to the interface connecting to CE1.
[PE1] ip vpn-instance vpna
[PE1-vpn-vpn-vpna] route-distinguisher 100:2
[PE1-vpn-vpn-vpna] vpn-target 100:1 both
[PE1-vpn-vpn-vpna] quit
[PE1] interface ethernet 2/0/0
[PE1-Ethernet2/0/0] ip binding vpn-instance vpna
[PE1-Ethernet2/0/0] ip address 168.1.1.1 255.255.0.0
[PE1-Ethernet2/0/0] quit
# Configure CE2.
[CE2] interface ethernet 1
[CE2-Ethernet1] ip address 168.2.2.2 255.255.0.0
[CE2-Ethernet1] quit
# Configure a VPN instance on PE2 and bind it to the interface connecting to CE2.
[PE2] ip vpn-instance vpna
[PE2-vpn-instance] route-distinguisher 200:2
[PE2-vpn-instance] vpn-target 100:1 both
[PE2-vpn-instance] quit
[PE2] interface ethernet 2/0/0
[PE2-Ethernet2/0/0] ip binding vpn-instance vpna
[PE2-Ethernet2/0/0] ip address 168.2.2.1 255.255.0.0
[PE2-Ethernet2/0/0] quit
After the configuration, you can view the VPN instance configuration by executing the
display ip vpn-instance verbose command on PEs. CEs can be pinged successfully
on PEs.
7-80
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
When pinging CE on PE, you need to specify the VPN to which the destination address
belongs.
For example, ping CE1 on PE1:
[PE1] ping -vpn-instance vpna 168.1.1.2
4)
Configuring MP-BGP, establishing IBGP peer relationship between PEs, and
establishing EBGP peer relationship between PE and CE
Note:
In this part:
z
The configurations on CE1, CE2, PE1, and PE2 are the same as those in section
7.4.9 “Configuring Inter-Provider Backbones Option A”.
z
Special configurations are necessary on ASBR-PE1 and ASBR-PE2: configuring
the undo policy vpn-target command in VPNv4 address family view and
configuring the next-hop-local command on IBGP peers in the AS.
# Configure CE1.
[CE1] bgp 65001
[CE1-bgp] group 20 external
[CE1-bgp] peer 168.1.1.1 group 20 as-number 100
[CE1-bgp] quit
# Configure PE1 to establish EBGP peer relationship with CE1 and IBGP peer
relationship with ASBR-PE1.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpna
[PE1-bgp-af-vpn-instance] group 10 external
[PE1-bgp-af-vpn-instance] peer 168.1.1.2 group 10 as-number 65001
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn-instance] quit
[PE1-bgp] group 20
[PE1-bgp] peer 202.100.1.1 group 20
[PE1-bgp] peer 202.100.1.1 connect-interface loopback0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpn] peer 20 enable
[PE1-bgp-af-vpn] peer 202.100.1.1 group 20
[PE1-bgp-af-vpn] quit
[PE1-bgp] quit
# Configure ASBR-PE1 to establish EBGP peer relationship with ASBR-PE2 and IBGP
peer relationship with PE1.
7-81
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] group 10 external
[ASBR-PE1-bgp] peer 192.1.1.2 group 10 as-number 200
[ASBR-PE1-bgp] group 20
[ASBR-PE1-bgp] peer 202.100.1.2 group 20
[ASBR-PE1-bgp] peer 202.100.1.2 connect-interface loopback0
[ASBR-PE1-bgp] ipv4-family vpnv4
[ASBR-PE1-bgp-af-vpn] peer 20 enable
[ASBR-PE1-bgp-af-vpn] peer 202.100.1.2 group 20
[ASBR-PE1-bgp-af-vpn] peer 20 next-hop-local
[ASBR-PE1-bgp-af-vpn] peer 10 enable
[ASBR-PE1-bgp-af-vpn] peer 192.1.1.2 group 10
[ASBR-PE1-bgp-af-vpn] undo policy vpn-target
[ASBR-PE1-bgp-af-vpn] quit
[ASBR-PE1-bgp] quit
# Configure CE2.
[CE2] bgp 65002
[CE2-bgp] group 10 external
[CE2-bgp] peer 168.2.2.1 group 10 as-number 200
[CE2-bgp] quit
# Configure PE2 to establish EBGP peer relationship with CE2 and IBGP peer
relationship with ASBR-PE2.
[PE2] bgp 200
[PE2-bgp] ipv4-family vpn-instance vpna
[PE2-bgp-af-vpn-instance] group 10 external
[PE2-bgp-af-vpn-instance] peer 168.2.2.2 group 10 as-number 65002
[PE2-bgp-af-vpn-instance] import-route direct
[PE2-bgp-af-vpn-instance] quit
[PE2-bgp] group 20
[PE2-bgp] peer 202.200.1.1 group 20
[PE2-bgp] peer 202.200.1.1 connect-interface loopback0
[PE2-bgp] ipv4-family vpnv4
[PE2-bgp-af-vpn] peer 20 enable
[PE2-bgp-af-vpn] peer 202.200.1.1 group 20
[PE2-bgp-af-vpn] quit
[PE2-bgp] quit
# Configure ASBR-PE2 to establish EBGP peer relationship with ASBR-PE1 and IBGP
peer relationship with PE2.
[ASBR-PE2] bgp 200
[ASBR-PE2-bgp] group 10 external
[ASBR-PE2-bgp] peer 192.1.1.1 group 10 as-number 100
7-82
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[ASBR-PE2-bgp] group 20
[ASBR-PE2-bgp] peer 202.200.1.2 group 20
[ASBR-PE2-bgp] peer 202.200.1.2 connect-interface loopback0
[ASBR-PE2-bgp] ipv4-family vpnv4
[ASBR-PE2-bgp-af-vpn] peer 20 enable
[ASBR-PE2-bgp-af-vpn] peer 202.200.1.2 group 20
[ASBR-PE2-bgp-af-vpn] peer 20 next-hop-local
[ASBR-PE2-bgp-af-vpn] undo policy vpn-target
[ASBR-PE2-bgp-af-vpn] peer 10 enable
[ASBR-PE2-bgp-af-vpn] peer 192.1.1.1 group 10
[ASBR-PE2-bgp-af-vpn] quit
[ASBR-PE2-bgp] quit
After completing the configuration, you can find that the BGP peer relationship has
been established in Established state between PEs and between PE and CE by
executing the display bgp vpnv4 all peer command on the firewalls.
CEs can learn interface routes from each other. CE1 and CE2 can be pinged
successfully on each other.
When a PE works as an ASBR at the same time, it needs to retain all VPNv4 routing
information and advertise it to other ASBRs. To this end, you must configure the undo
policy vpn-target command on it to have it receive all VPNv4 routing information
without filtering it based on VPN-target.
7.4.11 Configuring Inter-Provider Backbones Option C
I. Network requirements
CE1 and CE2 belong to the same VPN. CE1 accesses the network through PE1 in AS
100 and CE2 accesses the network through PE2 in AS 200.
Multi-AS BGP/MPLS VPN is implemented through Option C method. That is, labeled
VPN-IPv4 routes are advertised between PEs through Multihop MP-EBGP to manage
VPN routes.
II. Network diagram
See Figure 7-19.
III. Configuration procedure
According to the functions, the configuration procedures fall into four parts:
z
Configuring OSPF on the MPLS backbone network
z
Configuring basic MPLS capability on the MPLS backbone network
z
Configuring VPN instances on PEs
z
Configuring MP-BGP
Compared with Option A, Option C differs in the last two procedures.
7-83
Operation Manual – VPN
H3C SecPath Series Security Products
1)
Chapter 7 BGP/MPLS VPN Configuration
Configuring OSPF on the MPLS backbone network to make PEs learn routes from
each other
Note:
In this part:
The configurations on PE1 and PE2 are the same as those in section 7.4.10
“Configuring Inter-Provider Backbones Option B”.
# Configure PE1.
[PE1] interface loopback0
[PE1-LoopBack0] ip address 202.100.1.2 255.255.255.255
[PE1-LoopBack0] quit
[PE1] interface Ethernet1/0/0
[PE1-Ethernet1/0/0] ip address 172.1.1.2 255.255.0.0
[PE1-Ethernet1/0/0] quit
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 172.1.0.0 0.0.255.255
[PE1-ospf-1-area-0.0.0.0] network 202.100.1.2 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
# Configure ASBR-PE1.
[ASBR-PE1] interface loopback0
[ASBR-PE1-LoopBack 0] ip address 202.100.1.1 255.255.255.255
[ASBR-PE1-LoopBack 0] quit
[ASBR-PE1] interface Ethernet1/0/0
[ASBR-PE1-Ethernet1/0/0] ip address 172.1.1.1 255.255.0.0
[ASBR-PE1-Ethernet1/0/0] quit
[ASBR-PE1] interface Ethernet 2/0/0
[ASBR-PE1-Ethernet2/0/0] ip address 192.1.1.1 255.255.255.0
[ASBR-PE1-Ethernet2/0/0] quit
[ASBR-PE1] ospf
[ASBR-PE1-ospf-1] area 0
[ASBR-PE1-ospf-1-area-0.0.0.0] network 172.1.0.0 0.0.255.255
[ASBR-PE1-ospf-1-area-0.0.0.0] network 202.100.1.1 0.0.0.0
[ASBR-PE1-ospf-1-area-0.0.0.0] quit
[ASBR-PE1-ospf-1] quit
# Configure PE2.
[PE2] interface loopback0
7-84
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE2-LoopBack0] ip address 202.200.1.2 255.255.255.255
[PE2-LoopBack0] quit
[PE2] interface Ethernet1/0/0
[PE2-Ethernet1/0/0] ip address 162.1.1.2 255.255.0.0
[PE2-Ethernet1/0/0] quit
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1-area-0.0.0.0] network 162.1.0.0 0.0.255.255
[PE2-ospf-1-area-0.0.0.0] network 202.200.1.2 0.0.0.0
[PE2-ospf-1-area-0.0.0.0] quit
[PE2-ospf-1] quit
# Configure ASBR-PE2.
[ASBR-PE2] interface loopback0
[ASBR-PE2-LoopBack0] ip address 202.200.1.1 255.255.255.255
[ASBR-PE2-LoopBack0] quit
[ASBR-PE2] interface Ethernet1/0/0
[ASBR-PE2-Ethernet1/0/0] ip address 162.1.1.1 255.255.0.0
[ASBR-PE2-Ethernet1/0/0] quit
[ASBR-PE2] interface Ethernet 2/0/0
[ASBR-PE2-Ethernet2/0/0] ip address 192.1.1.2 255.255.255.0
[ASBR-PE2-Ethernet2/0/0] quit
[ASBR-PE2] ospf
[ASBR-PE2-ospf-1] area 0
[ASBR-PE2-ospf-1-area-0.0.0.0] network 162.1.0.0 0.0.255.255
[ASBR-PE2-ospf-1-area-0.0.0.0] network 202.200.1.1 0.0.0.0
[ASBR-PE2-ospf-1-area-0.0.0.0] quit
[ASBR-PE2-ospf-1] quit
After the configuration, the OSPF neighbor relationship should be established between
ASBR-PE and other PEs in the same AS. Executing the display ospf peer command,
you can find that the neighbor relationship is in Full state. PEs can learn Loopback
addresses from each other.
ASBR-PE and other PEs in the same AS can be pinged successfully on each other.
ASBR-PEs can be pinged successfully on each other.
2)
Configuring basic MPLS capability on the MPLS backbone network to make the
network forward VPN traffic
7-85
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
Note:
In this part:
The configurations on PE1 and PE2 are the same as those in section 7.4.10
“Configuring Inter-Provider Backbones Option B”.
It is necessary to configure MPLS capability for interfaces between ASBR-PEs.
# Configure basic MPLS capability on PE1 and enable LDP on the interface connecting
ASBR-PE1.
[PE1] mpls lsr-id 172.1.1.2
[PE1] mpls
[PE1-mpls] lsp-trigger all
[PE1-mpls] quit
[PE1] mpls ldp
[PE1] interface Ethernet1/0/0
[PE1-Ethernet1/0/0] mpls
[PE1-Ethernet1/0/0] mpls ldp enable
[PE1-Ethernet1/0/0] quit
# Configure basic MPLS capability on ASBR-PE1, enable LDP on the interface
connecting PE1, and enable MPLS on the interface connecting ASBR-PE2.
[ASBR-PE1] mpls lsr-id 172.1.1.1
[ASBR-PE1] mpls
[ASBR-PE1-mpls] lsp-trigger all
[ASBR-PE1-mpls] quit
[ASBR-PE1] mpls ldp
[ASBR-PE1] interface Ethernet1/0/0
[ASBR-PE1-Ethernet1/0/0] mpls
[ASBR-PE1-Ethernet1/0/0] mpls ldp enable
[ASBR-PE1-Ethernet1/0/0] quit
[ASBR-PE1] interface Ethernet2/0/0
[ASBR-PE1-Ethernet2/0/0] mpls
[ASBR-PE1-Ethernet2/0/0] quit
# Configure basic MPLS capability on ASBR-PE2, enable LDP on the interface
connecting PE2, and enable MPLS on the interface connecting ASBR-PE1.
[ASBR-PE2] mpls lsr-id 162.1.1.1
[ASBR-PE2] mpls
[ASBR-PE2-mpls] lsp-trigger all
[ASBR-PE2-mpls] quit
[ASBR-PE2] mpls ldp
[ASBR-PE2] interface Ethernet1/0/0
7-86
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[ASBR-PE2-Ethernet1/0/0] mpls
[ASBR-PE2-Ethernet1/0/0] mpls ldp enable
[ASBR-PE2-Ethernet1/0/0] quit
[ASBR-PE2] interface Ethernet2/0/0
[ASBR-PE2-Ethernet2/0/0] mpls
[ASBR-PE2-Ethernet2/0/0] quit
# Configure basic MPLS capability on PE2 and enable LDP on the interface connecting
ASBR-PE2.
[PE2] mpls lsr-id 162.1.1.2
[PE2] mpls
[PE2-mpls] lsp-trigger all
[PE2-mpls] quit
[PE2] mpls ldp
[PE2] interface Ethernet1/0/0
[PE2-Ethernet1/0/0] mpls
[PE2-Ethernet1/0/0] mpls ldp enable
[PE2-Ethernet1/0/0] quit
After the configuration, the LDP neighbor relationship should be established between
PE and ASBR-PE in the same AS. Executing the display mpls ldp session command
on the firewalls, you can find the Session State is “Operational" in the display result.
3)
Configuring VPN instances on PEs and binding to the interfaces connecting to
CEs
Note:
In this part:
The configurations on CE1, CE2, PE1, and PE2 are the same as those in section
7.4.10 “Configuring Inter-Provider Backbones Option B”.
# Configure CE1.
[CE1] interface ethernet 1
[CE1-Ethernet1] ip address 168.1.1.2 255.255.0.0
[CE1-Ethernet1] quit
# Configure a VPN instance on PE1 and bind it to the interface connecting to CE1.
[PE1] ip vpn-instance vpna
[PE1-vpn-vpn-vpna] route-distinguisher 100:2
[PE1-vpn-vpn-vpna] vpn-target 100:1 both
[PE1-vpn-vpn-vpna] quit
[PE1] interface ethernet 2/0/0
7-87
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[PE1-Ethernet2/0/0] ip binding vpn-instance vpna
[PE1-Ethernet2/0/0] ip address 168.1.1.1 255.255.0.0
[PE1-Ethernet2/0/0] quit
# Configure CE2.
[CE2] interface ethernet 1
[CE2-Ethernet1] ip address 168.2.2.2 255.255.0.0
[CE2-Ethernet1] quit
# Configure a VPN instance on PE2 and bind it to the interface connecting to CE2.
[PE2] ip vpn-instance vpna
[PE2-vpn-instance] route-distinguisher 200:2
[PE2-vpn-instance] vpn-target 100:1 both
[PE2-vpn-instance] quit
[PE2] interface ethernet 2/0/0
[PE2-Ethernet2/0/0] ip binding vpn-instance vpna
[PE2-Ethernet2/0/0] ip address 168.2.2.1 255.255.0.0
[PE2-Ethernet2/0/0] quit
After the configuration, you can see the VPN instance configuration by executing the
display ip vpn-instance verbose command on PEs. CEs can be pinged successfully
on PEs.
When pinging CE on PE, you need to specify the VPN to which the destination address
belongs.
For example, ping CE1 on PE1:
[PE1] ping -vpn-instance vpna 168.1.1.2
4)
Configuring MP-BGP, establishing IBGP peer relationship between PEs, and
establishing EBGP peer relationship between PE and CE
Note:
In this part:
z
The configurations on CE1 and CE2 are the same as those in section 7.4.10
“Configuring Inter-Provider Backbones Option B”.
z
The exchange of labeled IPv4 routes is configured between PE1 and ASBR-PE1,
PE2 and ASBR-PE2, ASBR-PE1 and ASBR-PE2.
z
ASBR-PE varies the next hop to itself when advertising routes to PEs in the same AS.
z
Route-policy is configured on ASBR-PE. For the routes received from PEs in the
same AS, ASBR-PE assigns MPLS labels for them when they are advertised to the
ASBR of the remote AS. For the routes advertised to PEs in the same AS, ASBR-PE
assigns new MPLS labels for them if they are labeled IPv4 routes.
7-88
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
# Configure CE1.
[CE1] bgp 65001
[CE1-bgp] group 20 external
[CE1-bgp] peer 168.1.1.1 group 20 as-number 100
[CE1-bgp] quit
# Configure PE1 to establish EBGP peer relationship with CE1, IBGP peer relationship
with ASBR-PE1, and Multihop MP-EBGP peer relationship with PE2.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpna
[PE1-bgp-af-vpn-instance] group 10 external
[PE1-bgp-af-vpn-instance] peer 168.1.1.2 group 10 as-number 65001
[PE1-bgp-af-vpn-instance] import-route direct
[PE1-bgp-af-vpn-instance] quit
[PE1-bgp] group 20
[PE1-bgp] peer 20 label-route-capability
[PE1-bgp] peer 202.100.1.1 group 20
[PE1-bgp] peer 202.100.1.1 connect-interface loopback0
[PE1-bgp] group 30 external
[PE1-bgp] peer 30 ebgp-max-hop
[PE1-bgp] peer 200.200.1.2 group 30 as-number 200
[PE1-bgp] peer 200.200.1.2 connect-interface loopback0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpn] peer 30 enable
[PE1-bgp-af-vpn] peer 200.200.1.2 group 30
[PE1-bgp-af-vpn] quit
[PE1-bgp] quit
# Configure route-policy on ASBR-PE1.
[ASBR-PE1] acl number 2001
[ASBR-PE1-acl-basic-2001] rule permit source 202.100.1.2 0
[ASBR-PE1-acl-basic-2001] rule deny source any
[ASBR-PE1-acl-basic-2001] quit
[ASBR-PE1] route-policy rtp-ebgp permit node 1
[ASBR-PE1-route-policy] if-match acl 2001
[ASBR-PE1-route-policy] apply mpls-label
[ASBR-PE1-route-policy] quit
[ASBR-PE1] route-policy rtp-ibgp permit node 10
[ASBR-PE1-route-policy] if-match mpls-label
[ASBR-PE1-route-policy] apply mpls-label
[ASBR-PE1-route-policy] quit
# Configure ASBR-PE1 to establish EBGP peer relationship with ASBR-PE2 and IBGP
peer relationship with PE1.
7-89
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] import-route ospf
[ASBR-PE1-bgp] group 10 external
[ASBR-PE1-bgp] peer 10 label-route-capability
[ASBR-PE1-bgp] peer 10 route-policy rtp-ebgp export
[ASBR-PE1-bgp] peer 192.1.1.2 group 10 as-number 200
[ASBR-PE1-bgp] group 20
[ASBR-PE1-bgp] peer 20 label-route-capability
[ASBR-PE1-bgp] peer 20 next-hop-local
[ASBR-PE1-bgp] peer 20 route-policy rtp-ibgp export
[ASBR-PE1-bgp] peer 202.100.1.2 group 20
[ASBR-PE1-bgp] peer 202.100.1.2 connect-interface loopback0
[ASBR-PE1-bgp] quit
# Configure CE2.
[CE2] bgp 65002
[CE2-bgp] group 10 external
[CE2-bgp] peer 168.2.2.1 group 10 as-number 200
[CE2-bgp] quit
# Configure PE2 to establish EBGP peer relationship with CE2, IBGP peer relationship
with ASBR-PE2, and Multihop MP-EBGP peer relationship with PE1.
[PE2] bgp 200
[PE2-bgp] ipv4-family vpn-instance vpna
[PE2-bgp-af-vpn-instance] group 10 external
[PE2-bgp-af-vpn-instance] peer 168.2.2.2 group 10 as-number 65002
[PE2-bgp-af-vpn-instance] import-route direct
[PE2-bgp-af-vpn-instance] quit
[PE2-bgp] group 20
[PE2-bgp] peer 20 label-route-capability
[PE2-bgp] peer 202.200.1.1 group 20
[PE2-bgp] peer 202.200.1.1 connect-interface loopback0
[PE2-bgp] group 30 external
[PE2-bgp] peer 30 ebgp-max-hop
[PE2-bgp] peer 202.100.1.2 group 30 as-number 100
[PE2-bgp] peer 202.100.1.2 connect-interface loopback0
[PE2-bgp] ipv4-family vpnv4
[PE2-bgp-af-vpn] peer 30 enable
[PE2-bgp-af-vpn] peer 202.100.1.2 group 30
[PE2-bgp-af-vpn] quit
[PE2-bgp] quit
# Configure route-policy on ASBR-PE2.
[ASBR-PE2] acl number 2001
7-90
Operation Manual – VPN
H3C SecPath Series Security Products
Chapter 7 BGP/MPLS VPN Configuration
[ASBR-PE2-acl-basic-2001] rule permit source 200.200.1.2 0
[ASBR-PE2-acl-basic-2001] rule deny source any
[ASBR-PE2-acl-basic-2001] quit
[ASBR-PE2] route-policy rtp-ebgp permit node 1
[ASBR-PE2-route-policy] if-match acl 2001
[ASBR-PE2-route-policy] apply mpls-label
[ASBR-PE2-route-policy] quit
[ASBR-PE2] route-policy rtp-ibgp permit node 10
[ASBR-PE2-route-policy] if-match mpls-label
[ASBR-PE2-route-policy] apply mpls-label
[ASBR-PE2-route-policy] quit
# Configure ASBR-PE2 to establish EBGP peer relationship with ASBR-PE1 and IBGP
peer relationship with PE2.
[ASBR-PE2] bgp 200
[ASBR-PE2-bgp] import-route ospf
[ASBR-PE2-bgp] group 10 external
[ASBR-PE2-bgp] peer 10 label-route-capability
[ASBR-PE2-bgp] peer 10 route-policy rtp-ebgp export
[ASBR-PE2-bgp] peer 192.1.1.1 group 10 as-number 100
[ASBR-PE2-bgp] group 20
[ASBR-PE2-bgp] peer 20 label-route-capability
[ASBR-PE2-bgp] peer 20 next-hop-local
[ASBR-PE2-bgp] peer 20 route-policy rtp-ibgp export
[ASBR-PE2-bgp] peer 202.200.1.2 group 20
[ASBR-PE2-bgp] peer 202.200.1.2 connect-interface loopback0
After the establishment of all BGP peer relationships, you can find the IPv4 route of the
peer, that is, 200.200.1.2 and 202.100.1.2 respectively on PE1 and PE2. Executing the
display bgp routing label command, you can find that the two routes carry labels and
the IPv4 routes learned from each other by PE1 and PE2.
CEs can learn interface routes from each other. CE1 and CE2 can be pinged
successfully on each other.
7-91
Download PDF
Similar pages