ZXR10 M6000 (V1.00.30) Carrier-Class Router Configuration Guide (VPN) PDF

ZXR10 M6000
Carrier-Class Router
Configuration Guide (VPN)
Version: V1.00.30
ZTE CORPORATION
NO. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
Fax: +86-755-26770801
URL: http://ensupport.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
Copyright © 2011 ZTE CORPORATION.
The contents of this document are protected by copyright laws and international treaties. Any reproduction or
distribution of this document or any portion of this document, in any form by any means, without the prior written
consent of ZTE CORPORATION is prohibited. Additionally, the contents of this document are protected by
contractual confidentiality obligations.
All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE
CORPORATION or of their respective owners.
This document is provided “as is”, and all express, implied, or statutory warranties, representations or conditions
are disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose,
title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the
use of or reliance on the information contained herein.
ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications
covering the subject matter of this document. Except as expressly provided in any written license between ZTE
CORPORATION and its licensee, the user of this document shall not acquire any license to the subject matter
herein.
ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice.
Users may visit ZTE technical support website http://ensupport.zte.com.cn to inquire related information.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Revision History
Revision No. Revision Date Revision Reason
R2.1 2011-05-10 Third release
The follwoing chapters are added.
l L2TP Configuration
The follwoing chapters are modified.
l MPLS L2 VPN Configuration

l MPLS L3 VPN Configuration
R2.0 2011-01-15 Second release, the document architecture is changed.
R1.0 2010-09-30 First release
Serial Number: SJ-20110504161056-016
Publishing Date: 2010-05-10 (R2.1)

Contents
About This Manual ......................................................................................... I
Chapter 1 Safety Instruction...................................................................... 1-1
1.1 Safety Instruction ............................................................................................... 1-1
1.2 Safety Signs ...................................................................................................... 1-1
Chapter 2 MPLS L2 VPN Configuration.................................................... 2-1

2.1 MPLS L2 VPN Overview..................................................................................... 2-1
2.1.1 MPLS L2 VPN Background ....................................................................... 2-1
2.1.2 MPLS L2 VPN Principle ............................................................................ 2-2
2.2 VPLS Basic Function Configuration ..................................................................... 2-3
2.2.1 VPLS Principle ......................................................................................... 2-3
2.2.2 Configuring VPLS..................................................................................... 2-5
2.2.3 VPLS Maintenance................................................................................. 2-10
2.2.4 VPLS Configuration Example .................................................................. 2-17
2.2.5 VPLS Fault Handling .............................................................................. 2-23
2.3 VPLS-MAC Filtering Configuration..................................................................... 2-28
2.3.1 VPLS-MAC Filtering Overview ................................................................ 2-28
2.3.2 VPLS-MAC Filtering Principle.................................................................. 2-28
2.3.3 Configuring VPLS MAC Filtering.............................................................. 2-28
2.3.4 VPLS-MAC Filtering Maintenance ........................................................... 2-29
2.3.5 VPLS-MAC Filter Configuration Example ................................................. 2-30
2.3.6 VPLS-MAC Filtering Fault Handling ......................................................... 2-33
2.4 VPLS Heterogeneous Function Configuration .................................................... 2-34
2.4.1 VPLS Heterogeneouse Function Overview .............................................. 2-34
2.4.2 Configuring the VPLS Heterogeneouse Function...................................... 2-35
2.4.3 VPLS Heterogeneouse Function Configuration Example........................... 2-36
2.4.4 VPLS Heterogeneouse Function Fault Handling ....................................... 2-38
2.5 VPWS Basic Function Configuration ................................................................. 2-41
2.5.1 VPWS Overview .................................................................................... 2-41
2.5.2 VPWS Principle...................................................................................... 2-41
2.5.3 Configuring VPWS ................................................................................. 2-42
2.5.4 VPWS Maintenance ............................................................................... 2-45
2.5.5 VPWS Configuration Examples ............................................................... 2-49
2.5.6 VPWS Fault Handling ............................................................................. 2-54
I
2.6 VPWS Heterogeneous Function Configuration ................................................... 2-56
2.6.1 VPWS Heterogeneous Function Overview ............................................... 2-56
2.6.2 VPWS Heterogeneous Function Principle ................................................ 2-57
2.6.3 Configuring the VPWS Heterogeneous Function ...................................... 2-57
2.6.4 VPWS Heterogeneous Function Maintenance .......................................... 2-58
2.6.5 VPWS Heterogeneous Function Configuration Example ........................... 2-59
2.6.6 VPWS Heterogeneouse Function Fault Handling...................................... 2-62
2.7 L2 VPN and L3 VPN Bridge Function Configuration............................................ 2-64
2.7.1 L2 VPN and L3 VPN Bridge Function Overview ....................................... 2-64
2.7.2 Configuring L2 VPN and L3 VPN Bridge Function .................................... 2-64
2.7.3 L2, L3VPN Bridge Configuration Example................................................ 2-65
2.7.4 L2 VPN and L3 VPN Bridge Fault Handling.............................................. 2-67
2.8 L2 VPN FRR Configuration ............................................................................... 2-69
2.8.1 Configuring L2 VPN FRR ........................................................................ 2-69
2.8.2 L2 VPN FRR Maintenance ...................................................................... 2-70
2.8.3 L2 VPN FRR Configuration Example ....................................................... 2-71
2.8.4 L2 VPN FRR Fault Handling ................................................................... 2-73
2.9 MAC Ping/MAC Trace Configuration.................................................................. 2-74
2.9.1 MAC Ping/MAC Trace Overview.............................................................. 2-74
2.9.2 MAC Ping/MAC Trace Principle............................................................... 2-75
2.9.3 Configuring MAC Ping/MAC Trace .......................................................... 2-76
2.9.4 MAC Ping/MAC Trace Configuration Example.......................................... 2-77
2.9.5 MAC Ping/MAC Trace Fault Handling ...................................................... 2-79
2.10 MC-ELAM Configuration ................................................................................. 2-82
2.10.1 MC-ELAM Overview ............................................................................. 2-82
2.10.2 MC-ELAM Principle .............................................................................. 2-82
2.10.3 Configuring MC-ELAM .......................................................................... 2-83
2.10.4 MC-ELAM Maintenance ........................................................................ 2-86
2.10.5 MC-ELAM Configuration Example ......................................................... 2-88
2.10.6 MC-ELAM Fault Handling ..................................................................... 2-91
Chapter 3 MPLS L3 VPN Configuration.................................................... 3-1

3.1 MPLS VPN Basic Function Configuration............................................................. 3-1
3.1.1 MPLS L3VPN Overview............................................................................ 3-1
3.1.2 Configuring MPLS L3VPN......................................................................... 3-5
3.1.3 MPLS VPN Maintenance ........................................................................ 3-16
3.1.4 MPLS VPN Configuration Examples ........................................................ 3-18
3.1.5 MPLS VPN Fault Handling ...................................................................... 3-30
II
3.2 MPLS VPN Route Aggregation Configuration..................................................... 3-37
3.2.1 MPLS VPN Route Aggregation Overview................................................. 3-37
3.2.2 Configuring MPLS VPN Route Aggregation.............................................. 3-37
3.2.3 MPLS VPN Route Aggregation Maintenance............................................ 3-38
3.2.4 MPLS VPN Route Aggregation Configuration Example ............................. 3-39
3.2.5 MPLS VPN Route Aggregation Fault Handling ......................................... 3-42
3.3 VPN Route Restriction and Alarm...................................................................... 3-46
3.3.1 VPN Route Restriction and Alarm Overview ............................................. 3-46
3.3.2 Configuring VPN Route Restriction and Alarm.......................................... 3-46
3.3.3 VPN Route Restriction and Alarm Maintenance........................................ 3-47
3.3.4 VPN Route Alarm Configuration Example ................................................ 3-49
3.3.5 VPN Route Restriction and Alarm Fault Handling ..................................... 3-52
3.4 L3 VPN FRR Configuration ............................................................................... 3-55
3.4.1 L3 VPN FRR Overview ........................................................................... 3-55
3.4.2 L3 VPN FRR Principle ............................................................................ 3-55
3.4.3 Configuring L3 VPN FRR ........................................................................ 3-56
3.4.4 L3 VPN FRR Maintenance ...................................................................... 3-56
3.4.5 L3 VPN FRR Configuration Example ....................................................... 3-56
3.4.6 L3 VPN FRR Fault Handling ................................................................... 3-60
3.5 MPLS VPN Load Balancing Configuration.......................................................... 3-62
3.5.1 MPLS VPN Load Balancing Overview...................................................... 3-62
3.5.2 LDP Load Balancing Configuration .......................................................... 3-63
3.5.3 VRF Load Balancing Configuration.......................................................... 3-70
Chapter 4 Multicast VPN Configuration ................................................... 4-1

4.1 VPN Multicast Overview ..................................................................................... 4-1
4.2 VPN Multicast Principle ...................................................................................... 4-1
4.3 Configuring VPN Multicast .................................................................................. 4-1
4.4 VPN Multicast Maintenance ................................................................................ 4-3
4.5 VPN Multicast Configuration Example.................................................................. 4-9
4.6 VPN Multicast Fault Handling............................................................................ 4-15
4.6.1 Network Topology................................................................................... 4-15
4.6.2 Fault Analysis ........................................................................................ 4-16
4.6.3 Handling Flow ........................................................................................ 4-16
4.6.4 Handling Procedure................................................................................ 4-17
Chapter 5 L2TP Configuration................................................................... 5-1

5.1 L2TP Overview .................................................................................................. 5-1
5.2 L2TP Principle ................................................................................................... 5-2
III
5.2.1 L2TP Network Structure............................................................................ 5-2
5.2.2 L2TP Function Overview........................................................................... 5-3
5.2.3 L2TP Negotiation Procedure ..................................................................... 5-4
5.2.4 LTS Function Overview............................................................................. 5-7
5.3 Configuring L2TP ............................................................................................... 5-8
5.4 L2TP Maintenance ............................................................................................5-11
5.5 L2TP Configuration Examples ........................................................................... 5-14
5.5.1 Configuring an LNS ................................................................................ 5-14
5.5.2 Configuring an LTS................................................................................. 5-16
5.6 L2TP Fault Handling......................................................................................... 5-19
5.6.2 Fault Analysis ........................................................................................ 5-19
5.6.3 Handling Flow ........................................................................................ 5-19
Chapter 6 GRE Configuration.................................................................... 6-1

6.1 GRE Overview ................................................................................................... 6-1
6.2 GRE Principle .................................................................................................... 6-2
6.2.1 GRE over IPv4 Tunnel .............................................................................. 6-2
6.2.2 GRE over IPv6 Tunnel .............................................................................. 6-2
6.3 Configuring GRE ................................................................................................ 6-3
6.3.1 Configuring GRE Over IPv4 Tunnel ........................................................... 6-3
6.3.2 Configuring GRE Over IPv6 Tunnel ........................................................... 6-5
6.4 GRE Maintenance .............................................................................................. 6-6
6.5 GRE Configuration Examples.............................................................................. 6-8
6.5.1 Basic GRE Configuration Example ............................................................ 6-8
6.5.2 GRE 6in4 Configuration Example ............................................................ 6-10
6.6 GRE Fault Handling ......................................................................................... 6-12
6.6.2 Fault Analysis ........................................................................................ 6-13
6.6.3 Handling Flow ........................................................................................ 6-13
Figures............................................................................................................. I
Tables .............................................................................................................V
Glossary .......................................................................................................VII
IV
About This Manual
Purpose
At first, thank you for choosing ZXR10 routers of ZTE Corporation!
This manual describes the principle, configuration commands, maintenance commands,
configuration examples and fault handling about VPN function of ZXR10 M6000.
Intended Audience
This manual is intended for the following engineers:
l Network planning engineer
l Commissioning engineer
l On-duty personnel
What Is in This Manual

This manual contains the following contents:
Chapter Summary
Chapter 1 Safety Instruction Introduces safety instruction and symbol description for device
installation, operation and maintenance.
Chapter 2 MPLS L2VPN Describes the MPLS L2VPN principle, configuration commands,
Configuration maintenance commands, configuration examples and fault
handling.
Chapter 3 MPLS L3VPN Describes the MPLS L3VPN principle, configuration commands,
handling.
Chapter 4 Multicast VPN Describes the Multicast VPN principle, configuration commands,
handling.
Chapter 5 L2TP Configuration Describes the L2TP principle, configuration commands,

maintenance commands, configuration examples and fault
handling.
Chapter 6 GRE Configuration Describes the GRE principle, configuration commands,

maintenance commands, configuration examples and fault
handling.
Conventions
ZTE documents employ the following typographical conventions.
I
Typeface Meaning
Italics Variables in commands. It may also refers to other related manuals and documents.
Bold Menus, menu options, function names, input fields, option button names, check boxes,
drop-down lists, dialog box names, window names, parameters and commands.
CAPS Keys on the keyboard and buttons on screens and company name.
Constant Text that you type, program codes, filenames, directory names, function names.
width
[] Optional parameters.
{} Mandatory parameters.
| Separates individual parameter in series of parameters.
Danger: Indicates an imminently hazardous situation, which if not avoided, will result in
death or serious injury.
Warning: Indicates a hazard that, if not avoided, could result in serious injuries,
equipment damages or interruptions of major services.
Caution: Indicates a potential hazard that, if not avoided, could result in moderate
injuries, equipment damages or partial service interruption.
Note: Provides additional information about a certain topic.
Checkpoint: Indicates that a particular step needs to be checked before proceeding

further.
Tip: Indicates a suggestion or hint to make things easier or more productive for the
reader.
II
Chapter 1
Safety Instruction
Table of Contents
Safety Instruction .......................................................................................................1-1
Safety Signs ...............................................................................................................1-1
1.1 Safety Instruction

Only duly trained and qualified personnel can install, operate and maintain the devices.
During the device installation, operation and maintenance, please abide by the local
safety specifications and related operation instructions, otherwise physical injury may
occur or devices may be broken. The safety precautions mentioned in this manual are
only supplement of local safety specifications.
The debug commands on the devices will affect the performance of the devices, which
may bring serious consequences. So take care to use debug commands. Especially, the
debug all command will open all debug processes, so this command must not be used on
the devices with services. It is not recommended to use the debug commands when the
user networks are in normal state.
ZTE Corporation will assume no responsibility for consequences resulting from violation
of general specifications for safety operations or of safety rules for design, production and
use of the devices.
1.2 Safety Signs

The information that users should pay attention to when they install, operate and maintain
devices are explained in the following formats:
Warning!
Indicates the matters needing close attention. If this is ignored, serious injury accidents
may happen or devices may be damaged.
Caution!
Indicates the matters needing attention during configuration.
1-1
SJ-20110504161056-016|2010-05-10 (R2.1) ZTE Proprietary and Confidential

ZXR10 M6000 Configuration Guide (VPN)
Note:
Indicates the description, hint, tip, and so on for configuration operations.
1-2

Chapter 2
MPLS L2 VPN Configuration
Table of Contents
MPLS L2 VPN Overview ............................................................................................2-1
VPLS Basic Function Configuration............................................................................2-3
VPLS-MAC Filtering Configuration ...........................................................................2-28
VPLS Heterogeneous Function Configuration ..........................................................2-34
VPWS Basic Function Configuration ........................................................................2-41
VPWS Heterogeneous Function Configuration .........................................................2-56
L2 VPN and L3 VPN Bridge Function Configuration .................................................2-64
L2 VPN FRR Configuration ......................................................................................2-69
MAC Ping/MAC Trace Configuration ........................................................................2-74
MC-ELAM Configuration...........................................................................................2-82
2.1 MPLS L2 VPN Overview

2.1.1 MPLS L2 VPN Background
In the past, enterprise Virtual Private Network (VPN) network usually rent a data link
(Frame Relay (FR) or Asynchronous Transfer Mode (ATM)) to form L2 VPN. Internet
Service Provider (ISP) only need to ensure the connectivity in data link layer, while user
can control the route and select L3 protocol flexibility. Moreover, the security of user VPN
is relatively superior under such a condition. However, for an ISP, the conventional Internet
traffic is completely separated from VPN traffic in FR or ATM network. Additional, there
is a problem of full-mesh connection in conventional L2 VPN. Therefore, this traditional
superposition L2 VPN brings heavy load to network maintenance and management.
People generally think that Multi Protocol Label Switching (MPLS) network is the
development direction of the next generation core network. The obvious advantage of
MPLS network is that it supports VPN service well. Using network of MPLS technology to
provide L2 VPN, ISP only needs to maintain and manage the single network infrastructure,
but it can provide both of L2 and L3 VPN services and various flexible Internet Protocol
(IP) services. The configuration of VPN service is more automatic.
There are several types of L2 VPN services,
l Virtual Private Wire Service (VPWS)
The communication between every two sites in VPN is realized by point to point
connection. VPWS is mainly used by ATM and FR users. The connection between
user and network provider is not changed but the service is encrypted and transmitted
over IP backbone network.
2-1

l Virtual Private LAN Service (VPLS)

To connect all the user LANs and provide L2 switch service, it emulates operator
network to a LAN switch or bridge. The difference between VPLS and VPWS is that
VPWS provides point to point service only while VPLS provides point to multi-points
services. That is, Customer Edge (CE) device on VPWS selects a virtual wire to
send data to a user site, while CE device on VPLS sends all data to be sent to the
destination to the connected Provider Edge (PE) device only.
l MSPW
Multi-Segmented PW (MSPW): Usually, it is also called Multi-Hop Pseudo Wire (PW).
MSPW means that a PW consists of multiple segmented PWs. It is used to accomplish
a cross-domain PW.
l VLSS
VLSS: It provides a connection between local CEs.
2.1.2 MPLS L2 VPN Principle

VPWS: VPWS is to establish a special line and provide L2 transparent transmission service
on the basis of MPLS network. It belongs to point-to-point L2 VPN service. The principle
is shown in Figure 2-1.
Figure 2-1 VPWS Working Principle
VPWS working mode: point-to-point.

The establishment procedure of a VPWS Virtual Connection (VC) is described below.
1. LSP establishment: A Label Switch Path (LSP) is established through MPLS network.
2. VC allocation: Local PE configures a VCID, allocates a VC label and interacts with the
remote PE.
3. PW establishment: Two PEs interact for negotiation through mapping messages to
establish a PW.
VPLS: VPLS is to provide Ethernet emulation services on MPLS network. It connects

several Local Area Networks (LANs) / Virtual Local Area Networks (VLANs) together. It
belongs to multipoint-to-multipoint L2 VPN service. The principle is shown in Figure 2-2.
2-2

Chapter 2 MPLS L2 VPN Configuration
Figure 2-2 VPLS Working Principle
VPLS: An ISP provides multipoint-to-multipoint L2 connections in a metropolitan area or

between metropolitan areas through extensible IP/MPLS network. For users, the sites in
different places look like a simple Ethernet LAN.
Users can realize LANs of their own through Metropolitan Area Network (MAN) or Wide
Area Network (WAN).
2.2 VPLS Basic Function Configuration

2.2.1 VPLS Principle
There are some VPLS terms,
l Access Circuit (AC)
It is a link between user and service provider, that is to say, the connection between
CE and PE. Ethernet interfaces are usually used in access circuit.
l PW
It is a bidirectional virtual connection between Virtual Switch Interfaces (VSIs) on a
pair of PE devices. It is composed of a pair of unidirectional MPLS Virtual Circuit (VC)
with opposite direction. It is also called emulation circuit.
l TAG
TAG is added by service provider to distinguish users. It is called Service Delimiting
(SDT), also called PTAG.
VPLS working principle is shown in Figure 2-3.
2-3

Figure 2-3 VPLS Working Principle
VPLS working flow is described below.

VPLS establishes full connection of PW among the VPLS instances of PE1, PE2 and PE3.
All the VPLS instances belonging to a VPLS domain use the same VCID.
Here, PE1 allocates VC tags 102 and 103 to PE2 and PE3 respectively. PE2 allocates VC
tags 201 203 to PE1 and PE3. PE3 allocates VC tags 301 and 302 to PE1 and PE2.
Assume that a host connecting to CE1 sends a Medium Access Control (MAC) frame
containing source MAC address X and destination MAC address Y through PE1. If PE1
does not know the destination PE, it encapsulates a tag 201 to the MAC frame and then
sends the MAC frame to PE2, and it encapsulates a tag 301 to the MAC frame and then
sends the MAC frame to PE3.
After PE2 receiving the MAC frame, it judges that the host connecting to PE1 according to
the tag 201, thus it can learn the MAC address X and bind the X to tag 102 (allocated by
PE1).
There are two modes for PW emulating Ethernet, Raw and Tagged modes.
l In Raw mode, the type of PW is Ethernet. The packets are transmitted in PW without
PTAG. PTAG will be removed if an AC packet containing PTAG is transmitted in PW.
The information of VLAN tag will not be changed in PW transmission if the AC packet
is transmitted without PTAG.
l In Tag mode, the type of PW is Ethernet-VLAN. The packets are transmitted in PW
with PTAG. PTAG will be kept with the AC packet to transmit to the peer PE if the AC
packet contains PTAG. A PTAG or a special PTAG-Vlan 0tag is encapsulated into the
AC packet if the AC packet is transmitted in PW without PTAG.
Caution!
In both of RAW and Tag modes, the user VLAN tags locating at frame headers are
transmitted transparently without any changing.
There are two modes for MAC address learning, qualified and unqualified modes.
2-4

l Qualified mode
PE learns MAC address according to the MAC address and VLAN tag containing in
user Ethernet packet. In qualified mode, every user VLAN has its own broadcast
domain and independent MAC address space.
l Unqualified mode
PE learns MAC address according to the MAC address containing in user Ethernet
packet. In unqualified mode, all user VLANs share a broadcast domain and a MAC
address space. The MAC address of user VLAN has to be unique. The MAC
addresses cannot be repeated.
PW has two transmission modes, Spoke and Hub modes. To solve the full-connection
broadcast loop and realize the hierarchical accessing, people define PW transmission
attributes Spoke and Hub modes and AC Server/Client mode. In VPLS working
mechanism, PE router broadcasts (flooding) broadcast, multicast and unknow frames to
other network members. The broadcast rules of different modes are described below.
l Broadcast the broadcast packets received from a Spoke mode PW to all ACs (Client
and Server), Hub mode PWs and other Spoke mode PWs.
l Broadcast the broadcast packets received from a Server (Server-AC) to other ACs
(Client and Server), all Spoke mode PWs and Hub mode PWs.
l Broadcast the broadcast packets received from a Hub mode PW to all Server-ACs
and Spoke mode PWs, but not broadcast to other Hub mode PWs and all Client-ACs.
l Broadcast the broadcast packets received from a Client (Client-AC) to all Server-ACs
and Spoke mode PWs, but not broadcast to Hub mode PWs and other Client-ACs.
2.2.2 Configuring VPLS

To configure VPLS on ZXR10 M6000, perform the following steps.
Step Command Function
1 ZXR10(config)#vpls < vpls-name> This creates a VPLS instance.
2 ZXR10(config)#sdu < 1-55968> This creates a Service Data

Unit (SDU) interface in global
configuration mode. It is necessary
to create an SDU interface before the
SDU is bound to a VPLS instance.
3 ZXR10(config)#pw-redundancy-manager pw_redundancy < This configures a PW redundancy

1-55968> backup group in global configuration
mode. After this configuration, the
redundancy backup group can be
bound to an SDU in Step 7.
2-5

4 ZXR10(config-vpls)#sac < ac-interface> [ client] This specifies an interface to be

bound as an access link and enter
sac configuration mode.
ZXR10(config-vpls)#sdu < sdu-number> This binds an SDU to the current

VPLS instance, specifies the working
mode to hub forwarding mode and
enters SDU configuration mode.
ZXR10(config-vpls)#spoke-sdu < sdu-number> This binds an SDU to the current

VPLS instance, specifies the working
mode to spoke forwarding mode
and enters spoke-sdu configuration
mode.
ZXR10(config-vpls)#default-vcid < vcid> This configures the default VCID of

VPLS service.
ZXR10(config-vpls)#mac This enters mpls mac configuration

mode.
ZXR10(config-vpls)#mac-withdraw This enables mac-withdraw function.
ZXR10(config-vpls)#mtu < mtu> This sets the Maximum Transmission

Unit (MTU) of an instance.
5 ZXR10(config-vpls-sac)#service-define ethernet This sets an AC to ethernet type.
6 ZXR10(config-vpls-sac-sd)#group-id < 1-63> This configures Clien-group-id.
ZXR10(config-vpls-sac-sd)#ingress-adjust { no-pop-outermost | This configures VLAN translation

push { < 1-4094> | dummy-tag } } (only supported by qualify instance).
7 ZXR10(config-vpls-sdu)#neighbour < A.B.C.D> [ < vcid value> ] This configures a PW and binds an
SDU (if the < vcid value> parameter
is not configured, it is necessary to
configure the default VCID in VPLS
configuration mode in advance).
8 ZXR10(config-vpls-sdu-pw)#control-word { used | unused } This sets a PW to use the control

word or not.
ZXR10(config-vpls-sdu-pw)#vccv cc { pw-ach| ttl=1| alert-label} This sets a PW to support Virtual

cv { bfd { with-ip/udp-header| without-ip/udp-header} | lsp-ping| Circuit Connectivity Verification
icmp-ping} [ status-signalling] (VCCV).
ZXR10(config-vpls-sdu-pw)#tunnel-policy { auto| mpls-te < This modifies the outer tunnel policy
TE-interface> } of a PW.
ZXR10(config-vpls-sdu-pw)#signal { dynamic | static local < This sets the establishment mode of
16-4095> remote < 16-4096> } a PW to signal triggering.
2-6

ZXR10(config-vpls-sdu-pw)#encapsulation { tagged | raw } This sets the encapsulation mode of

a PW.
9 ZXR10(config-vpls-spoke-sdu)#neighbour < A.B.C.D> [ < vcid> This configures a PW and binds

] [ backup] a SPOKE SDU (if the < vcid>
parameter is not configured, it is
necessary to configure the default
vcid in VPLS configuration mode in
advance).
ZXR10(config-vpls-spoke-sdu)#redundancy-manager This binds a PW redundancy backup

pw_redundancy< 1-55968> group to the current spoke-sdu
or enters PW redundancy backup
group manager configuration mode.
10 ZXR10(config-vpls-spoke-sdu-pw)#control-word { used| unused } This sets a PW to use the control

word or not.
ZXR10(config-vpls-spoke-sdu-pw)#vccv cc { pw-ach| ttl=1| This sets a PW to support VCCV.

alert-label} cv { bfd { with-ip/udp-header| without-ip/udp-header} |
lsp-ping| icmp-ping} [ status-signalling]
ZXR10(config-vpls-spoke-sdu-pw)#tunnel-policy { auto| mpls-te This modifies the outer tunnel policy

< TE-interface> } of a PW.
ZXR10(config-vpls-spoke-sdu-pw)#signal { dynamic | static local This sets the establishment mode of

< 16-4095> remote < 16-4096> } a PW to signal triggering.
ZXR10(config-vpls-spoke-sdu-pw)#encapsulation { tagged | raw } This sets the encapsulation mode of

a PW.
ZXR10(config-vpls-spoke-sdu-pw)#group-id < 1-63> This configures Clien-group-id of a

VPLS PW.
11 ZXR10(config-vpls-spoke-sdu-rm)#pfs-bits { independent | master This configures PW negotiation

| slave | unused } mode.
Descriptions of the parameters in Step 4:
Parameter Description
< ac-interface> Name of the interface that specifies as an access link
< sdu-number> SDU interface number, in the range of 1-55968
< mtu> MTU of VPLS service
< vcid> VCID of VPLS service. The VCID set here becomes the default VCID.
Descriptions of the parameter in Step 5:
2-7

ethernet Sets an AC to ethernet type
< group-id> Clien-group-id value
no-pop-outermost Not pop out the label
push< 1-4094> Pushes a label. The range of the label is 1–4094.
push dummy-tag Pushes the label 0
< vcid> The VCID used by the PW, in the range of 1-4294967295. if this
parameter is not configured, it is necessary to configure the default
VCID in VPLS configuration mode in advance.
< A.B.C.D> Remote Label Switch Router (LSR) ID
used PW uses the control word.
unused PW does not use the control word.
cc Specifies the VCCV control-channel type
pw-ach The Connection Confirmation (CC) type is PW access channel

(PW-ACH control word).
ttl=1 The CC type is inner Time To Live (TTL) = 1.
alert-label The CC type is MPLS alert label.
cv Specifies VCCV connectivity-very type
bfd The CV type is PW-BFD.
without-ip/udp-header Bidirectional Forwarding Detection (BFD) messages do not contain

IP/User Datagram Protocol (UDP) header (by default, the messages
contain IP/UDP header).
status-signalling Sets BFD session to support status signalling or not
lsp The CV type is PW-PING.
icmp The CV type is ICMP-PING.
< TE-interface> TE tunnel name
2-8

auto Selects any LSP matched by DIP
dynamic Dynamic PW
static Static PW
< 16-4095> PW label range
tagged PW uses Tagged mode.
raw PW uses Raw mode.
< A.B.C.D> Remote LSR ID
< vcid> The VCID used by the PW, in the range of 1-4294967295. if this
parameter is not configured, it is necessary to configure the default
vcid in VPLS configuration mode in advance.
[ backup] Un-negotiated backup PW
redundency-manager pw_redundancy< The name of a PW redundancy group, in the range of 1-55968

1-55968>
pw-ach The CC type is PW access channel (PW-ACH control word).
ttl=1 The CC type is inner TTL = 1.
without-ip/udp-header BFD messages do not contain IP/UDP header (by default, the
messages contain IP/UDP header).
2-9

dynamic Dynamic PW
static Static PW
tagged PW uses Tagged mode.
raw PW uses Raw mode.
{ < group-id> } Clien-group-id value
independent Sets PW redundancy negotiation mode to independent
master Sets PW redundancy negotiation mode to master
slave Sets PW redundancy negotiation mode to slave
unused Cancels PW redundancy negotiation mode
2.2.3 VPLS Maintenance

ZXR10 M6000 provides the following commands to maintain VPLS.
Command Function
ZXR10#show l2vpn brief This shows the list of LSVPN service

instances and the binding number of
instance AC and PW.
ZXR10#show l2vpn summary < name> This shows the number of L2VPN
instances.
ZXR10#show l2vpn forwardinfo [ vpnname < vpn-name> | peer < A.B.C.D> This shows the valid PW list according
[ vcid < 1-4294967295> ] ] [ detail] to the instance name or peer ID.
ZXR10#show pwe3 signal [ [ peer < ip-address> ] [ vcid < vcid> ] [ pw-type This shows the information summary of
< pw-type> ] | local-label < value> | remote-label < value> | service-type PW.
{ vpls| vpws| mspw} [ id < value> | name < instance-name> ] | used-only|
unuse-only [ no-remote| no-config] ]
ZXR10#show pwe3 signal [ [ peer < ip-address> ] [ vcid < vcid> ] [ pw-type This shows the PW information in detail,
< pw-type> ] | local-label < value> | remote-label < value> | service-type and lists the reason that PW is down.
{ vpls| vpws| mspw} [ id < value> | name < instance-name> ] | used-only|
unuse-only [ no-remote| no-config] ] detail
ZXR10#show pwe3 signal statistic This shows the static information of PW

signalling states.
2-10

An example of the show l2vpn brief command output is shown below.

ZXR10(config)#show l2vpn brief
VPLS count:1 VPWS count:0 VLSS count:0 MSPW count:1
name type Default-VCID PW AC description
vpls_1 VPLS unqualified 0 1 1
mspw_1 MSPW - 0 0
ZXR10(config)#
Descriptions of the command output:
Command Output Description
VPLS count The number of VPLS instances
VPWS count The number of VPWS instances
VLSS count The number of VLSS instances
MSPW count The number of MSPW instances
name Instance name
type Instance type
default vcid The default vcid value
PW The number of PW in an instance
AC The number of AC in an instance
description Instance description information
An example of the show l2vpn summary command output is shown below.

ZXR10(config)#show l2vpn summary
The summary information about configured L2VPN:
vpn type configure/maximum
VPLS 0/8000
VPWS 1/8000
MSPW 0/8000
VLSS 0/8000
vpn type VPN type
configure/maximum Number of instance configured/maximum number of instance supported
An example of the show l2vpn forwordinfo command output is shown below.

PE2(config)#show l2vpn forwardinfo
Hearders: PWType - Pseudowire type and Pseudowire connection mode
Local - Local label, Remote - Remote label
VPNowner - owner type and instance name
2-11

Codes: H - HUB mode, S - SPOKE mode, L - VPLS, W - VPWS, M - MSPW
PeerID VCID PWType State Local Remote VPNowner

100.100.1.1 20 ETH UP 81920 81920 W: vpws_zte1
PeerID The router ID of the PW peer
VcID PW vcid
PWType PW type
State PW state
Local Local label
Remote Remote label
VPNowner The VPN type and name of the PW
An example of the show l2vpn forwardinfo detail command output is shown below.
ZXR10#show l2vpn forwardinfo detail
Hearders : ALLOK - Pseudowire Forwarding
PWNF - Pseudowire Not Forwarding
AR - Local AC (ingress) Receive Fault
AT - Local AC (egress) Transmit Fault
PSNR - Local PSN-facing PW (ingress) Receive Fault
PSNT - Local PSN-facing PW (egress) Transmit Fault
PWFS - Pseudowire forwarding standby
RS - Request switchover to this PW
PWSA - Pseudowire Status All Fault
Codes : -unknown, *yes, .no
-------------------------------------------------------------------------------
Service type and instance name:[VPLS jixi]

Peer IP address : 100.10.10.1 VC status : UP
Connection mode : HUB VC ID : 10
Signaling protocol : LDP VC type : ETH
Last status change time : 00:09:00 Create time : 01:31:39
MPLS VC local label : 81920 Remote label : 81920
SDU name : sdu1 Control Word : DISABLE
Remote status : ALLOK PW FRR type : NULL
Tunnel label : { 3 }
Output interface : gei-0/0/0/8
Imposed label stack : { 81920 3 }
2-12

MPLS VC TYPE PW type
VC status VC state
Destination address Peer PE id
VC ID VCID value
Connection mode PW C/S attribute
Control Word Whether the control word is used
Last status change time The time when the instance state is changed the last time
Create time The time when the instance is created
Signaling protocol Signaling protocol
VCCV value VCCV value
MPLS VC local label Local VC label
Remote label Remote VC label
SDU name SDU used by the instance
PW FRR Type Fast Reroute (FRR) type
Remote status Remote status
Tunnel label Tunnel label (this is a public tunnel label)
Output interface Egress that forwards the instance
Imposed label stack Label stack
An example of the show pwe3 signal command output is shown below.
ZXR10(config)#show pwe3 signal

The signal information of dynamic PWs:
Hearders : C - Configured, R - Received, N - Negotiated, S - Sent,
A - AC ready, local - local label，remote - remote label,
owner - application instance of PW, sesn - the LDP session's state,
use - signal procedures succeeded and VC-LSPs formed,
NON - the LDP session is absent,
UP - the LDP session is OPERATIONAL,
GR1 - the LDP session is reconnecting,
2-13

GR2 - the LDP session's remote mappings are recovering,

DOWN - not UP(or NON,or GR1,or GR2).
Codes : ?unknown, *yes, .no
-----------------------------------------------------------------------------
remote-pe-id vcid pw-type local remote use CRNSA type owner sesn
---------------- ------- --------- ------- ------- --- ----- ---- ----- ----
1.1.1.100 1004 ethernet ? 32771 NO .*... ---- ? UP
1.1.1.100 1003 ethernet 32774 32770 NO ***.* MSPW 3 UP
1.1.1.1 1003 ethernet 32773 ? NO *...* MSPW 3 NON
remote-pe-id The peer address
vcid PW vcid
pw-type PW type
local Local tag
remote Remote tag
use Indicate whether the tag is allocated
CRNSA PW state information
type Application type
owner PW vpnid
sesn Session state
An example of the show pwe3 signal detail command output is shown below.
ZXR10#show pwe3 signal detail
The detailed signal information of dynamic PWs:
Some signal information are referred to as follows :

PW entity : <100.10.10.1 , 10 , ethernet>

LSPs formed : YES
C-bits : local : NO , remote : NO
negotiated : NO
MTU : local : 1500 , remote : 1500
negotiated : 1500
labels : local : 81920 , remote : 81920
2-14

signal : Configured : YES , Received : YES

Negotiated : YES , Sent : YES
AC ready : YES
application : service-type : VPLS , instance-id: 2
local-VCCV : CC-type : NO , CV-type : NO
remote-VCCV : CC-type : NO , CV-type : NO
actual-VCCV : CC-type : NO , CV-type : NO
LDP session : The LDP session's state is UP.
attachment-circuit : ??
local-description : ??
remote-description : ??
PW entity The peer address, vcid and PW type
LSPs formed Indicate whether it is used in data layer.
C-bits Control word information
C-bits: local Indicate whether the local end support CWORD
C-bits: remote Indicate whether the peer signalling message showing supports CWORD.
C-bits: negotiated Indicate whether negotiation result supports CWORD
Labels Tag information
Lable: local Local tag value
Lable: remote Remote tag value
signal Signalling information
Configured Indicate whether the local is configured
Received Indicate whether the peer mapping message is received.
Negotiated Indicate whether the signalling negotiation is successful
Sent Indicate whether local end sends mapping message to the peer
AC ready Indicate whether the interface binding is up (for VPWS).
application Application information
service-type Application type
instance-id VPN instance ID
LDP session Label Distribution Protocol (LDP) session state
attachment-circuit The name of binding interface (VPWS binding interface)
local-description Local interface description (interface name)
remote-description Remote interface description
An example of the show pwe3 signal statistic command output is shown below.
2-15

ZXR10#show pwe3 signal statistics

The statistics of dynamic PWs or PW-segments:
Headers : APP - application instance of PW, C-bit - the PWs using control word,
ether - the ethernet raw PWs, vlan - the ethernet tagged PWs,
others - the non-ethernet PWs,
used - signal procedures succeeded and VC-LSPs or transit-LSPs formed
Codes : ?application instance not configured
----+-----+------------------+------------------------+------------------------
type|count| all dynamic PWs | the used dynamic PWs | the unused dynamic PWs
of | of +------------------+------------------------+------------------------
APPs|APPs |total used unused|C-bit ether vlan others|C-bit ether vlan others
----+-----+-----+-----+------+-----+-----+-----+------+-----+-----+-----+------
VPWS 0 0 0 0 0 0 0 0 0 0 0 0
VPLS 1 1 1 0 0 1 0 0 0 0 0 0
MSPW 0 0 0 0 0 0 0 0 0 0 0 0
???? 0 0 0 0 0 0 0 0 0 0 0 0
------------------------------------------------------------------------------
SUM 1 1 1 0 0 1 0 0 0 0 0 0
type of APPs Application type
count of APPs Instance number
all dynamic PWs All dynamic PW informations
total PW total number
used The PW used in data layer
unused The PW unused in data layer
the used dynamic PWs The condition of PW used in data layer
C-bit Support CWORD
ether PW type is ethernet-raw
vlan PW type is ethernet-tagged
others PW is other type
the unused dynamic PWs The condition of PW unused in data layer
C-bit Support CWORD
ether PW type is ethernet-raw
vlan PW type is ethernet-tagged
others PW is other type
2-16

2.2.4 VPLS Configuration Example

Configuration Description
The network topology of an L2VPN VPLS un-qualified configuration example is shown in
Figure 2-4.
Figure 2-4 Network Structure of L2VPN VPLS Un-Qualified Configuration
Configuration Thought
1. Configure necessary information on the interfaces of CE1 and CE2 connected to PEs.
The interfaces are on the same Ethernet.
2. Configure information on the interfaces of PE1 and PE2 connected to CEs. If the
sub-interfaces are used as ACs, it is necessary to configure VLAN/QinQ encapsulation
on the sub-interfaces.
3. Configure information on the interconnected interfaces between PE1 and PE2 to make
PE1 interconnect to PE2. Configure loopback interfaces on PE1 and PE2 and use
them as LDP router-IDs.
4. Configure routing information to advertise the loopback interface addresses. Make
sure that the next hop/egress of the routes are the LDP public network interfaces in
the next step.
5. Configure an LDP instance. Enable MPLS LDP function on the interconnected
interfaces between PE1 and PE2. Use the interfaces as LDP public network
interfaces. PE1 and PE2 are directly connected, so it is unnecessary to establish a
target-session.
6. Configure a VPLS instance. Make sure that the VPLS neighbors are consistent with
LDP neighbors.
Configuration Comamnds
Configuration on PE1:
Configure addresses on the direct-connected interface between PEs and the loopback
interface:
PE1(config)#interface gei-0/1/0/2
PE1(config-if)#ip address 100.10.1.1 255.255.255.0
PE1(config-if)#no shutdown
PE1(config-if)#exit
PE1(config)#interface loopback1
2-17

PE1(config-if)#exit
Configure routing protocol:

PE1(config)#router ospf 1
PE1(config-ospfv2)#network 100.10.10.1 0.0.0.0 area 0.0.0.0
PE1(config-ospfv2)#exit
Configure LDP:
PE1(config)#mpls ldp instance 1
PE1(config-ldp)#router-id loopback1
PE1(config-ldp)#interface gei-0/1/0/2
PE1(config-ldp-if)#exit
PE1(config-ldp)#exit
Configure L2VPN VPLS:

PE1(config)#mpls l2vpn enable
PE1(config)#sdu sdu1 /*Create an SDU*/
PE1(config)#vpls zte1
PE1(config-vpls)#sdu sdu1
PE1(config-vpls-sdu)#neighbour 100.10.10.2 10
/*Configure the peer IP and VCID. By default, it is RAW mode.*/
PE1(config-vpls-sdu-pw)#exit
PE1(config-vpls-sdu)#exit
PE1(config-vpls)#sac gei-0/1/0/1.1 /*Configure an interface at AC side*/
PE1(config-vpls-sac)#service-define ethernet
/*This command is mandatory. Otherwise AC members do not take effect.*/
PE1(config-vpls-sac-sd)#end
Configure addresses on the direct-connected interface between PEs and the loopback
interface:
PE2(config-if)#exit
PE2(config-if)#ip addr 100.10.10.2 255.255.255.255
PE2(config-if)#exit
Configure routing protocol:

2-18


Configure LDP:
Configure L2VPN VPLS:

PE2(config)#sdu sdu1
PE2(config)#vpls zte2
PE2(config-vpls)#sac gei-0/1/0/1.1
PE2(config-vpls-sac)#service-define ethernet
PE2(config-vpls-sac-sd)#end
Configuration Verification
Check the configuration results. Take PE1 as an example. The procedure to check the
configurations on PE2 is the same as that to check the configurations on PE1.
1. Use the show running-config ospf command to check whether the route configuration
is correct, and use the show ip forwarding route command to view the configuration
result, as shown below.
PE1#show running-config ospf
! <OSPF>
router ospf 1
network 100.10.10.1 0.0.0.0 area 0.0.0.0
/*Advertise the address that will be used as the address of a PW neighbor in VPLS.
When configuring LDP, make sure that this address is used as the LDP router-id,
and use this address to establish an LDP session.*/
network 100.10.1.1 0.0.0.0 area 0.0.0.0
/*Advertise the address on the interface directly connected to the peer PE.
Use this address to establish a connection with the OSPF neighbor.*/
!
! /<OSPF>
PE1#show ip for route 100.10.10.2
IPv4 Routing Table:
status codes: *valid, >best
Dest Gw Interface Owner Pri Metric
*> 100.10.10.2/32 100.10.1.2 gei-0/1/0/2 ospf 110 1
2-19

After the route configuration, the route to the router-id of the VPLS PW neighbor and
also the LDP peer is generated. The local egress interface is gei-0/1/0/2, and the next
hop address is 100.10.1.2.
2. Use the show running-config ldp command to check whether the LDP configuration
is correct, and use the show mpls ldp neighbor instance command to check the
configuration result of LDP neighbor establishment, as shown below.
PE1#show running-config ldp
! <MPLS>
mpls ldp instance 1
router-id loopback1
interface gei-0/1/0/2
/*Do enable MPLS LDP on the egress interface of the route to the LDP neighbor.*/
$
! /<MPLS>
PE1#show mpls ldp neighbor instance 1
Peer LDP Ident: 100.10.10.2:0; Local LDP Ident: 100.10.10.1:0
/*Peer LDP Ident<——>Local LDP Ident, the possible LDP peer is 100.10.10.2:0.
Try to establish an LDP session for this peer.*/
TCP connection: 100.10.10.2.2278 - 100.10.10.1.646
/*The TCP connection to the possible peer is established successfully.
The transmission address to establish a connection is not configured
in this example, so the default router-id is used.*/
State: Oper; Msgs sent/rcvd: 80/72; Downstream
/*The TCP connection to the possible peer is established successfully.
LDP neighbor negotiation on the TCP connection suceeds. The LDP session
to the peer is established successfully (LDP session UP). The information
"ldp state:Oper" means that the LDP session is established successfully.*/
Up Time: 00:54:04
LDP discovery sources:
gei-0/1/0/2; Src IP addr: 100.10.1.2
/*Send LDP discovery packets to through gei-0/1/0/2. The session between
100.10.10.2:0 and 100.10.10.1:0 is maintained by this interface. If the
interface becomes down, the session will be closed.*/
Addresses bound to peer LDP Ident:
100.10.1.2 100.10.10.2 /*The addresses that can be used as LSP
public network interface addresses on the LDP peer*/
2-20

Note:
To establish a VPLS PW, it is necessary to check wether the LDP session to the
specified neighbor exists. This the session does not exist, signalling to establish PW
will not be sent, and the PW cannot be established.
3. Use the show mpls ldp bindings command on PE2 to check whether LDP distributes
the local label of public network for the PW neighbor. After the label is mapped to PE1,
check whether it is marked “inuse” as a remote label.
PE2#show mpls ldp bindings 100.10.10.2 32 detail instance 1
100.10.10.2/32
local binding: label: imp-null
advertised to:
100.10.10.1:0
remote binding: lsr: 100.10.10.1:0, label: 16484
PE1#show mpls ldp bindings 100.10.10.2 32 detail instance 1
100.10.10.2/32
local binding: label: 16484
advertised to:
100.10.10.2:0
remote binding: lsr: 100.10.10.2:0, label: imp-null(inuse)
PE2 distributes an explicit null label {3} for the local loopback address 100.10.10.2.
PE1 learns the label 3 distributed for 100.10.10.2 by PE2. The label is marked “inuse”.
4. Use the show mpls forwarding command to check whether the label distributed to
the PW neighbor is written to the label forwarding table, and use the ping mpls ipv4
command to check whether the public network tunnel to the specified PW neighbor is
established successfully.
PE1#show mpls forwarding-table
Local Outgoing Prefix or Outgoing Next Hop M/S
label label Tunnel Id interface
16484 Poptag 100.10.10.2/32 gei-0/5/0/8 100.10.1.2 M
PE1#ping mpls ipv4 100.10.10.2 32
sending 5,120-byte MPLS echos to 100.10.10.2,timeout is 2 seconds.
Codes: '!' - success, 'Q' - request not transmitted,
'.' - timeout, 'U' - unreachable,
'R' - downstream router but not target
!!!!!
Success rate is 100 percent(5/5),round-trip min/avg/max= 1/1/1 ms.
5. Use the show pwe3 signal command to check whether the local device can send
signalling to establish a PW. In normal situations, if the LDP session to the specified
PW neighbor exists in the results of Step 2, PWE3 signalling can be sent.
PE1#show pwe3 signal detail
2-21


PW entity : < 100.10.10.2 , 10 , ethernet >
LSPs formed : YES
negotiated : NO
negotiated : 1500
AC ready : YES
application : service-type : VPLS , instance-id: 1
6. Use the show l2vpn forwardinfo comamnd to check whether the PW is established
successfully, and use the detail keyword to check the detailed information of the inner
and the outer labels for this PW.
PE1#show l2vpn forwardinfo vpnname zte1
Llabel - Local label, Rlabel - Remote label
PeerIP VCID PWType State Llabel Rlabel VPNowner
100.10.10.2 10 ETH H UP 81920 81920 L: zte1
PE1#show l2vpn forwardinfo vpnname zte1 detail
Hearders : ALLOK - Pseudowire Forwarding
PWNF - Pseudowire Not Forwarding
AR - Local AC (ingress) Receive Fault
AT - Local AC (egress) Transmit Fault
PSNR - Local PSN-facing PW (ingress) Receive Fault
PSNT - Local PSN-facing PW (egress) Transmit Fault
PWFS - Pseudowire forwarding standby
RS - Request switchover to this PW
PWSA - Pseudowire Status All Fault
2-22

Codes : -unknown, *yes, .no

----------------------------------------------------------------------------
Service type and instance name:[VPLS zte1]
Peer IP address : 100.10.10.2 VC status : UP
Connection mode : HUB VC ID : 10
Signaling protocol : LDP
Last status change time : 00:02:48 Create time : 01:10:34
MPLS VC local label : 81920 Remote label : 81920
SDU name : sdu1 Control Word : DISABLE
Remote status : ALLOK PW FRR type : NULL
Tunnel label : { 3 }
/*This tunnel is a public network tunnel instead of a TE tunnel.*/
Output interface : gei-0/1/0/2
/*Check whether the output interface is correct*/
Imposed label stack : { 81920 3 }
7. Use the ping mpls pseudowire command to check whether the PW is established
correctly.
PE1#ping mpls pseudowire 100.10.10.2 10 ether
sending 5,120-byte MPLS echos to 100.10.10.2,timeout is 2 seconds.

'.' - timeout, 'U' - unreachable,
!!!!!
Success rate is 0 percent(0/5).
After the VPLS application, the two CE devices can ping each successfully.
CE1#ping 10.1.1.2
sending 5,100-byte ICMP echoes to 10.1.1.2,timeout is 2 seconds.
!!!!!
CE2#ping 10.1.1.1
!!!!!
2.2.5 VPLS Fault Handling

2.2.5.1 Network Topology
Take the topology shown in Figure 2-5 as an example to describe how to handle a VPLS
fault.
2-23

Figure 2-5 Network Topology of a VPLS Fault
2.2.5.2 Fault Analysis

Symptom: VPL forwarding tunnel cannot be established, or the VPL forwarding tunnel is
in DOWN state.
If the VPLS forwarding tunnel is not established, it is possible that the VPLS peer is not
configured. If the VPLS peer is configured, but the forwarding tunnel (the VC tunnel) is
down, analyze the possible causes.
1. PE devices distribute two labels to establish a VPLS VC forwarding tunnel. The
devices distribute outer labels to establish a public network tunnel to transmit packets
from a PE to the peer PE. The devices distribute inner VC labels to establish a PW
to identify different VPLS instances and identify PW connections to different peers. It
is recommended to establish a PW through LDP. The public network tunnel can be
established through LDP LSP or Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE). Generally, LDP is used.
2. Here, assume that the outer tunnel is established through LDP. Establish an LDP
session between PEs. After the session is up (that is, the LDP neighbor is up),
distribute an outer label to the specified VPLS peer to establish an LSP to the VPLS
peer.
3. PW signalling is transmitted through LDP. It is necessary to transmit the PW signalling
on the LDP session directing to the specified VPLS peer. After the VPLS peer is
configured on the PE and the LDP session directing to the VPLS peer is established
successfully (LDP neighbor = VPLS peer), the PW is established on the PE. The PE
distributes a VC local label for the PW. PW negotiation packets and mapping messages
are sent on the LDP session in up state directing to the VPLS peer to advertise the
VC local label. After the VC labels are advertised to each other and the negotiation
succeeds, the PW becomes up.
4. When two PEs establish an LSP successfully, the PW is established and the VC label
negotiation succeeds, the VC tunnel is up.
5. In such a situation, the fault may be caused one of the following reasons: The VPLS
peer is not configured. There is no route to the VPLS peer, so the LDP session to the
VPLS peer cannot be established, and so the PW cannot be established. The LSP to
2-24

the VPLS peer cannot be established (it is necessary to check whether a public network
label id redistributed to the VPLS peer, and whether the label is marked “inuse”).
Symptom: VPLS forwarding tunnel is up, but traffic cannot be forwarded properly.
The VC tunnel is up, so the inner and the outer labels are distributed correctly. It is
necessary to check the configurations from the PEs to the CEs, and check whether the
planned VPLS PW and AC attributes meet the requirement of forwarding. The procedure
is described below.
1. Check whether AC is configured on the PEs.
2. Check whether the configurations of CEs are correct. VPLS simulates a LAN, so the
CEs should be on the same network segment. If VLAN or QinQ interfaces are used,
make sure that the interface encapsulation modes are consistent.
3. VPLS forwarding complies with broadcast rules. Check whether the VPLS
configuration meets the requirement of forwarding.
2.2.5.3 Handling Flow

The flow to handle a VPLS fault is shown in Figure 2-6.
2-25

Figure 2-6 Flow to Handle a VPLS Fault
2.2.5.4 Handling Procedure

The procedure to handle a VPLS fault is described below.
Check whether the VPLS label forwarding tunnel (that is, the VC tunnel) is up.
2-26

Use the show l2vpn forwardinfo command to check whether the VPLS label forwarding
tunnel is up. If the tunnel is down, use the show l2vpn forwardinfo detail command to
check the detailed information. A VPLS label forwarding tunnel consists of a public network
tunnel and a private network PW. If the VC tunnel is down, there are two possible causes.
One is that the PW cannot be up. For this cause, perform Step 2 to Step 5. The other is
that the LSP cannot be established. It is necessary to check the configuration of the public
network tunnel, corresponding to Step 6.
1. Check whether the communications on the physical links to the peer PE are normal.
Use the show ip interface brief command to check whether the physical state is up.
Check the connections on the interfaces. Make sure that the connections are correct
and the direct-links can be pinged successfully.
2. Check whether a peer is configured in the VPLS instance. Check whether the
configurations of the PW parameters are consistent.
Use the show running-config l2vpn command to check whether the peer device is set
to the neighbor (that is, the VPLS peer) in SDU configuration mode on both PEs. If
there is no peer, PW cannot be established. In such a situation, the VPLS can only
be used for the communication between local ACs. On both PEs, check whether the
VCIDs and PW types of the PWs are the same respectively on both directions. During
PW establishment, it is necessary to negotiate these parameters. If the parameters
are not consistent, the negotiation will fail, and the PW cannot be up.
3. Check whether there is a route to the VPLS peer.
Check whether the configuration of Interior Gateway Protocol (IGP) (such as Open
Shortest Path First (OSPF)) is correct. Use the show running-config ospf command
to check whether the route of the 32–bit VPLS peer address is advertised. If the
configurations are correct, use the show ip ospf neighbor command to check the
establishment of OSPF neighbor relationship until the neighbor state is FULL. Use
the show ip forwarding route command to check whether the route is generated. Pay
attention to the egress interface and next hop of the route.
4. Check whether there an LDP session directing to the VPLS peer.
The signalling used by VPLS is an extended signalling of LDP. To establish a PW
between VPLS peers, both peers need to transmit the signalling. So the LDP session
directing to the VPLS peer is mandatory. If the session does not exist, the PW cannot
be up. Use the show running-config ldp command to check the following information.
a. Whether the LDP router-id is the address of the VPLS peer.

b. Whether MPLS LDP is enabled on the egress interface of the route directing to
the VPLS peer.
c. Whether all the interfaces on which MPLS LDP is enabled use the default TCP
connection establishment transmission address.
Use the show mpls ldp neighbor command to check the establishment of LDP neighbor
relationship until the state is Oper.
2-27

5. Check whether the PW to the VPLS peer is up.

Use the show pwe3 signal command to check whether the PW state is up. If the state is
down, use the show pwe3 signal detail command to view the detailed information and
check whether there is any information indicating that the LDP session cannot learn
the remote VC label.
6. Check whether the public tunnel to the VPLS peer is established.
LDP LSP is a kind of public tunnel usually used. Use the show mpls forwarding-table
command to check whether the label forwarding table to the VPLS peer is formed.
If the Outgoing label of the forwarding entity corresponding to the VPLS peer is
untagged, use the show mpls ldp bindings detail command to check the binding of
the FEC. Check whether a label are distributed for the VPLS peer, and whether the
label is marked “inuse”. If the label is not marked “inuse”, the corresponding entity
in the output of the show mpls forwarding-table command is untagged, which means
that the LSP cannot be established. Please switch to LDP fault handling and refer to
related information in ZXR10 M6000 (V1.00.30) Carrier-Class Router Configuration
Guide (MPLS Volume).
If the fault cannot be solved according to the steps above, please ask for technical support.
2.3 VPLS-MAC Filtering Configuration

2.3.1 VPLS-MAC Filtering Overview
VPLS MAC filtering function satisfies the requirements for VPLS network access security
and controllability. ZXR10 M6000 filters the MAC addresses of VPLS packets according
to the filter rules defined by users, thus, it can restrict VPLS MAC learning and VPLS
forwarding.
2.3.2 VPLS-MAC Filtering Principle

VPLS MAC filtering uses global restriction in VPLS instance, that is to say, the rule is
applied in a specific VPLS instance. When MAC filtering rule is applied in the VPLS
instance, all MAC addresses of this rule will be synchronized to forwarding table and set
drop tag. Bottom layer forwarding module searches forwarding table to find these MAC
addresses and drop according to the tag.
In this way, the route entries which contain the source and destination MAC addresses
defining by VPLS instance are filtered, thus to, the hosts to be filtered are shielded in
network.
2.3.3 Configuring VPLS MAC Filtering

To configure VPLS-MAC filtering on ZXR10 M6000, perform the following steps.
2-28

1 ZXR10(config)#vpls < name> [ qualified] This creates L2VPN VPLS service

instance.
If this command is used without [
qualified] , it uses unqualified setting.
2 ZXR10(config-vpls-name)#mac This enters VPLS instance

configuration mode.
3 ZXR10(config-vpls-mac-name)#filter { source | both | destination} < This filters data frames according to
mac-address> [ vlan < vlan-id> ] MAC addresses in VPLS instance.
< name> VPLS instance name, with 1–32 characters
[ qualified] MAC learning policy. Learn MAC address in the specified VLAN.
source Filter data frames according to source MAC addresses
both Filter data frames according to the source or destination MAC addresses.
destination Filter data frames according to the destination MAC address
< mac-address> MAC address, in dotted decimal notation
< vlan-id> VLAN ID, in the range of 1–4094.

In qualified mode, specify MAC address to learn in the VLAN by using
this parameter.
2.3.4 VPLS-MAC Filtering Maintenance

ZXR10 M6000 provides the following command to maintain VPLS-MAC filtering.
Command Function
ZXR10(config)#show vpls-mac vpls < name> This shows the configured MAC
address entries in VPLS instance.
An example of the show vpls-mac vpls command output is shown below.

ZXR10# show vpls-mac vpls aaa
MAC_address VLAN peer-address outInterface type
------------------------------------------------------
00d0.d0c0.1320 0 12.1.1.1 PINTF_3 dynamic
2-29

MAC_address MAC address
VLAN VLAN ID
peer-address The peer IP address
outInterface Egress interface
type MAC address type (dynamic is dynamic type)
2.3.5 VPLS-MAC Filter Configuration Example

VPLS MAC filter satisfies the requirements for VPLS network access security and
controllability. It filters the source and destination MAC addresses of VPLS packets
according to user-defined filter rules, thus to filter VPLS MAC learning and forwarding.
The network structure is shown in Figure 2-7.
Figure 2-7 VPLS-MAC Filter Configuration Example
1. Establish VPLS connection between PE1 and PE2.
2. Enter VPLS MAC configuration mode on PE, configure MAC filter rule.
Configuration Commands
PE1(config)#vpls vpls_a
2-30

PE1(config-if)#exit
PE1(config-if)#exit
PE2(config-if)#exit
PE2(config-if)#exit
Check the configuration on PE1, as shown below.
/*View PW connection*/
PE1(config)#show l2vpn forwardinfo vpls_a
name:vpls_a type:VPLS unqualified PW count:1
description:
/*Here, the UP means that PW connection is successful.*/
PeerID VcID Type Mode CW State Local Remote linkto tunnelID
1.1.1.2 100 VLAN Hub UP 32768 32770 pw1 N-114
2-31

View the configuration of MAC filtering:

/*Here, there is MAC filter policy. It is null.*/
PE1(config)#show running-config mac
CE1 sends the data frames which source MAC address
is 0000.0000.1111 and CE2 sends the data frames which source
MAC address is 0000.0000.222.
View MAC learning,
PE1(config)#show vpls-mac vpls vpls_a
/*Here, the dynamic means the MAC address is learnt dynamically.*/
MAC vlan peer-address outInterface type
---------------------------------------------------------------
0000.0000.1111 0 NULL gei-0/1/0/2 dynamic
/*Local source MAC address filter is not configured.*/
0000.0000.2222 0 1.1.1.2 pw1 dynamic
/*Remote source MAC address filter is not configured.*/
Add MAC filter configuration on PE1, as shown below.

PE1(config-vpls-vpls_a)#mac
PE1(config-vpls-mac-vpls_a)#filter source 0000.0000.1111
PE1(config-vpls-mac-vpls_a)#filter source 0000.0000.2222
Check the filtering on PE1, as shown below

/*View MAC filtering*/
PE1(config)#show running-config mac
vpls vpls_a
mac
filter source 0000.0000.2222
/*Filter source MAC 0000.0000.2222, no learning*/
filter source 0000.0000.1111
/*Filter source MAC 0000.0000.1111, no learning*/
!
CE1 sends the data frames containing source MAC 0000.0000.1111
and CE2 sends the data frames containing source MAC 0000.0000.2222.
View MAC learning,
PE1(config-vpls-mac-vpls_a)#show vpls-mac vpls vpls_a
/*Here, the src filter means that source filtering and not
learn source MAC.*/
MAC VLAN peer-address outInterface type
----------------------------------------------------------------
0000.0000.2222 0 NULL NULL src filter
/*Remote source MAC filter is configured.*/
0000.0000.1111 0 NULL NULL src filter
/*Local source MAC filter is configured.*/
2-32

2.3.6 VPLS-MAC Filtering Fault Handling

Take the topology shown in Figure 2-8 as an example to describe how to handle a
VPLS-MAC filtering fault.
Figure 2-8 Network Topology of a VPLS-MAC Filtering Fault

Symptom:
The MAC address to be filtered still can be learned and seen in the MAC table.
Fault analysis:
Inspect whether the attributes source, destination and both are configured correctly in MAC
filtering rule.

The flow to handle a VPLS-MAC filtering fault is shown in Figure 2-9.
2-33

Figure 2-9 Flow to Handle a VPLS-MAC Filtering Fault

The procedure to handle a VPLS-MAC filter fault is described below.
1. Use the show running-config mac command to check the configuration. Make sure that
the configuration is correct.
2. Check whether the VPLS state and basic configuration are correct.
3. Clear the MAC address table, and wait the device to learn MAC addresses again.
2.4 VPLS Heterogeneous Function Configuration

2.4.1 VPLS Heterogeneouse Function Overview
VPLS heterogeneouse function means that heterogeneous medias are interconnected
by VPLS, which mainly includes the interconnection between Packet Over SONET/SDH
(POS) bridge interface and Ethernet interface by VPLS.
VPLS heterogeneouse applies the mode that POS interface is mapped to general Ethernet
interface. Therefore VPLS heterogeneouse mainly completes port mapping, the binding
between general logic Ethernet interface and VPLS instance. But general logic interface
2-34

has Ethernet attribute on the interface and support the binding of VPLS instance. The
main work of VPLS heterogeneouse is port mapping.
When a POS interface is enabled BCP bridge function, it needs to be bound to a logic
Ethernet interface to implement bridge function. At this time, configure Ethernet interface
service on this logic Ethernet interface. These services include layer 2 forwarding service.
For upper layer protocol, not POS physical port but logic Ethernet interface is seen. At this
time, this interface is taken as ordinary Ethernet interface.
For forwarding layer, after POS interface is enabled BCP bridge service, the service that
this interface supports and the resolution and encapsulation mode for packet are similar
with Ethernet interface.
2.4.2 Configuring the VPLS Heterogeneouse Function

There are the following steps to configure the VPLS heterogeneouse function on ZXR10
M6000.
1. Enable BCP bridge function on POS interface mode.
2. Create a logic Ethernet interface.
3. Map POS interface to ulei interface.
4. Add a VPLS instance into ulei interface.
To configure the VPLS heterogeneouse function on ZXR10 M6000, use the following
commands.
1 ZXR10(config-ppp)#interface pos < pos-number> This enters into POS interface

configuration mode.
2 ZXR10(config-ppp-if)#ppp bcp enable This enables BCP bridge function on

POS interface mode.
3 ZXR10(config)#request interface ulei< ulei-number> This creates a logic Ethernet

interface, that is, ulei interface. The
range of < ulei-number> is 1-64.
4 ZXR10(config)#interface pos < pos-number> This enters into POS interface

configuration mode.
5 ZXR10(config-if)#map-to ulei1 This maps POS interface to ulei

interface.
6 ZXR10(config)#vpls zte This enters into VPLS configuration

mode.
2-35

7 ZXR10(config-vpls-zte)#interface sac ulei< ulei-number> This adds a VPLS instance into ulei
interface.
2.4.3 VPLS Heterogeneouse Function Configuration Example

The modern network requires supporting heterogeneouse mediums to interconnect
devices through VPLS. On such a network, POS bridge interfaces can interconnect with
GE, FE interfaces through VPLS. GE interface and FE interface can be directly bind to
a VPLS instance. It is necessary to map an POS interface to a ulei interface before it is
bould to a VPLS instance. A typical VPLS heterogeneouse network is show in Figure
2-10.
Figure 2-10 VPLS Heterogeneouse Function Configuration Example
1. Create the routes among PE1, PE2 and PE3.
2. Establish LDP neighbor relationship between PE1 and PE2, between PE1 and PE3,
or between PE2 and PE3.
3. Enable MPLS L2VPN on PE1, PE2 and PE3. Establish a PW. Configure a VPLS
instance and configure the corresponding remote member.
4. Because GE interfaces and FE interfaces can be directly bould to a VPLS instance,
make a POS interface as a AC to connect to a VPLS instance by mapping it to a
physical GE or FE interface. Route-id of each device is shown below.
Device name route-id
PE1 1.1.1.1
2-36

Device name route-id
PE2 2.2.2.2
PE3 3.3.3.3
VPLS heterogeneouse configuration is mainly completed on PE2. For the configuration on
other PEs, please refer to VPLS configuration. The configuration of POS bridge interface
on PE2 and the configuration of the VPLS instance are as follows.
PE2(config)#ppp
PE2(config-ppp)#interface pos12-0/1/0/1
PE2(config-ppp-if)#no ppp ipcp enable
PE2(config-ppp-if)#ppp bcp enable
PE2(config-ppp-if)#exit
PE2(config-ppp)#exit
PE2(config)#request interface ulei-0/1/0/1
PE2(config-ulei-if)#exit
PE2(config)#interface pos12-0/1/0/1
PE2(config-if)#map-to ulei-0/1/0/1
PE2(config-if)#exit
PE2(config)#vpls zte
PE2(config-vpls)#sac ulei-0/1/0/1
PE2(config-vpls-sac)#exit
PE2(config-vpls)#exit
PE2(config)#
Check the configuration result on PE2.
PE2(config)#show running-config-interface pos12-0/1/0/1
!<INTERFACE>
interface pos12-0/1/0/1
index 23
!
!</INTERFACE>
!<PMAP>
2-37

map-to ulei-0/1/0/1
!
!</PMAP>
!<PPP>
ppp
ppp bcp enable
no ppp ipcp enable
!</PPP>
PE2#show l2vpn forwardinfo vpnname zte
Codes: H - HUB mode, S - SPOKE mode, L - VPLS,
W - VPWS, M - MSPW PeerID
VCID PWType State Local Remote VPNowner
1.1.1.1 10 VLAN H UP 81920 81920 L: zte
3.3.3.3 10 VLAN H UP 81921 81920 L: zte
2.4.4 VPLS Heterogeneouse Function Fault Handling

Take the topology shown in Figure 2-11 as an example to describe how to handle VPLS
heterogeneous function fault.
Figure 2-11 Network Topology of a VPLS Heterogeneous Function Fault

Symptom: VPLS PW link fails to be established or the link is in DOWN state.
Fault analysis: PW link fails to be established or the link is in DOWN state.
2-38

1. Check whether the peer is configured when VPLS instance is configured. Without the
peer configuration, the link fails to be established.
2. If the peer configuration is already configured, check whether the vcid is same to the
pwtype. Make sure that them are correct.
3. If the vcid and pwtype are the same, check whether LDP neighbor is established suc-
cessfully. PW cannot be created if the LDP neighborhood fails to be established.
Check whether IGP neighbor is established. Make sure that IGP neighbors can ping
the transmission address between each other. (By default, it is the Router-ID.)
4. If LDP link is established but PW is still in DOWN state, check whether LDP allocates
tag to the destination FEC and encapsulates inuse tag. Meanwhile, check LDP
label allocation and tag filtering policy. Make sure that LDP can allocate tag to the
destination FEC and encapsulates inuse tag.
5. Check if POS interface is encapsulated into ulei interface correctly and has correct
mapping relation.

The flow to handle a VPLS heterogeneous function fault is shown in Figure 2-12.
2-39

Figure 2-12 Flow to Handle a VPLS Heterogeneous Function Fault
2-40


The procedure to handle a VPLS heterogeneous function fault is described below.
1. Inspect whether the states of links and interfaces are normal.
2. Inspect whether IGP (OSPF) is configured correctly by using the show running-config
ospf command. View the state of OSPF neighbor (until FULL state) by using the how
ip ospf neighbor command.
3. Inspect whether LDP is configured correctly by using the show running-config ldp
command. Make sure that the configuration is correct, and use the show mpls
ldp neighbor command to view the state of LDP neighbor until the connection is
established.
4. Inspect whether the label distribution is correct and the inuse label is encapsulated by
using the show mpls ldp bindings command. Use show running-config ldp to inspect
whether label distribution or filtering policies is configured. Inspect whether the policies
affect the label distribution. If the label distribution is affected, use the no command to
change or modify the rule (For more information, refer to LDP configuration).
5. Use the show running-config l2vpn command to check whether MPLS L2VPN is
enabled and whether the corresponding instance is configured. In order to realize the
interconnection between two sites, the same vcid and pwtype should be configured
on the instances. Use the show l2vpn forwarding vpnname command to view whether
the PW link is in UP state.
6. Use the show running-config-interface ulei command and the show running-config-inte
rface pos command to view the configuration of POS interface and ulei interface. POS
interface needs to be mapped to ulei interface, and ulei interface is bound to VPLS
instance.
2.5 VPWS Basic Function Configuration

2.5.1 VPWS Overview
VPWS uses point-to-point connection mode to implement communication among each site
within VPN. This mode is usually used for ATM or FR clients. With this mode, connection
between clients and network providers maintain constant, but services encapsulated are
transmitted over IP backbone network of the network provider.
2.5.2 VPWS Principle

LSP tunnel through MPLS net should be defined between two PE routers, and it should
provide tunnel label transparently transmitting data between two PE routers. At the same
time, direct process of LDP label distribution protocol is also defined between two PE
routers to transmit virtual link information. Among them, distributing VC Label through
matching VCID is critical.
2-41

When data packet enters PE router at the port of Layer 2 transparent transmission, PE
router finds the corresponding Tunnel Label and VC Label through matching VCID. PE
router will put two layers labels on the data packet. External layer is Tunnel Label indicating
the route from this PE router to destination PE router. Internal layer is VC Label indicating
which corresponding router port of VCID belongs to on destination PE router.
PE router should monitor Layer 2 protocol state at each port, such as FR Local
Management Interface (LMI) and ATM Interim Local Management Interface (ILMI). When
a fault occurs, users can cancel VC Label through LDP label distribution protocol process
so that Layer 2 transparent transmission is shut off avoiding producing unidirectional
unwanted data stream.
Such Layer 2 transparent transmission based on MPLS changes traditional confinement
that Layer 2 link should be implemented through network switch. It essentially forms a
pattern of One Net Multi-Service pattern and makes the operator provide Layer 2 and Layer
3 Services simultaneously in a MPLS net.
2.5.3 Configuring VPWS

To configure VPWS on ZXR10 M6000, perform the following steps.
1 ZXR10(config)#vpws < vpws-name> This creates a VPWS instance.
2 ZXR10(config-vpws)#sac < ac-interface> This binds an AC to an interface.
ZXR10(config-vpws)#sdu < sdu-name> This binds an SDU to an interface.
ZXR10(config-vpws)#mtu < mtu> This sets the MTU of an instance.
3 ZXR10(config-vpws-sac)#service-define{ ethernet} This sets an AC to ethernet type.
ZXR10(config-vpws-sac)#inter-networking ip This enters IP heterogeneous mode.
ZXR10(config-vpws-sac)#track < tarck-name> This configures BFD track instance

name.
4 ZXR10(config-vpws-sac-eth)#encapsulation { tagged | raw } This configures the encapsulation

mode of Customer Interface Point
(CIP) service.
ZXR10(config-vpws-sac-eth)#extra-service-delimiter { stp-bpdu} This configures VPWS to transmit

Spanning Tree Protocol (STP)
messages transparently.
ZXR10(config-vpws-sac-eth)#ingress-adjust { no-pop-outermost| This configures VLAN translation.

push { < 1-4094> | dummy-tag } }
5 ZXR10(config-vpws-sac-iwf-ip)#local-ce mac < mac-address> This configures local CE MAC

address.
2-42

6 ZXR10(config-vpws-sdu)#neighbour{ < A.B.C.D> } [ < This configures a PW and binds an

1-4294967295> ] [ backup] SDU.
ZXR10(config-vpws-sdu)#redundency-manager[ < RGroup-name> ] This configures the name of a PW

redundancy group.
7 ZXR10(config-vpws-sdu-pw)#control-word { used | unused } This sets a PW to use the control

word or not.
ZXR10(config-vpws-sdu-pw)#vccv cc{ pw-ach | ttl=1 | alert-label } This sets a PW to support VCCV.

cv { bfd [ status-signalling | without-ip/udp-header [ status-signalling
] ] | lsp | icmp}
ZXR10(config-vpws-sdu-pw)#tunnel-policy { auto| { mpls-te< This modifies the outer tunnel policy

TE-interface > } } of a PW.
ZXR10(config-vpws-sdu-pw)#signal { dynamic | static local < This sets the establishment mode of
16-4095> remote < 16-4096> } a PW to signal triggering.
8 ZXR10(config-vpws-sdu-rm)#pfs-bits { independent | master | slave This configures PW negotiation

| unused } mode.
< ac-interface> Name of the interface on which an AC is bound
< sdu-name> Name of the interface on which an SDU is bound
ethernet Sets an AC to ethernet type
< tarck-name> BFD Track instance name
tagged CIP uses tagged mode.
raw CIP uses raw mode.
stp-bpdu STP Bridge Protocol Data Unit (BPDU)
no-pop-outermost Not pop out the label
push < 1-4094> Pushes a label. The range of the label is 1–4094.
push dummy-tag Pushes the label 0
Descriptions of the parameter in Step:
2-43

< mac-address> Local CE MAC address
Descriptions of the parameters used by step 6 are shown below.
< A.B.C.D> Remote LSR ID
[ < 1-4294967295> ] VCID value
backup Un-negotiated backup PW
[ < RGroup-name> ] The name of a PW redundancy group
pw-ach The CC type is PW access channel (PW-ACH control word).
ttl=1 The CC type is inner TTL=1.
without-ip/udp-header BFD messages do not contain IP/UDP header (by default, the
messages contain IP/UDP header).
dynamic Dynamic PW
static Static PW
independent Sets PW redundancy negotiation mode to independent
master Sets PW redundancy negotiation mode to master
slave Sets PW redundancy negotiation mode to slave
unused Cancels PW redundancy negotiation mode
2-44

2.5.4 VPWS Maintenance

ZXR10 M6000 provides the following commands to maintain VPWS.
Command Function
ZXR10#show l2vpn brief This shows the list of LSVPN service

instances and the binding number of
each instance AC and PW.
ZXR10#show l2vpn summary This shows the number of L2VPN

instances.
ZXR10#show l2vpn forwordinfo vpnname [ < vpnname> | < detail> | < peer> ] This shows the valid PW list according
to the instance name.
ZXR10#show pwe3 signal [ { [ peer < A.B.C.D> ] [ vcid < value> ] [ This shows the information summary of
pw-type < pw-type> ] } | used-only | { unused-only [ no-remote | no-config PW.
] } | { service-type { vpws } [ id < value> ] } | { local-label < value> } | {
remote-label < value> } ]
ZXR10#show pwe3 signal detail[ { [ peer < A.B.C.D> ] [ vcid < value> ] [ This shows the PW information in detail,
pw-type < pw-type> ] } | used-only | { unused-only [ no-remote | no-config and lists the reason that PW is down.
] } | { service-type { vpws } [ id < value> ] } | { local-label < value> } | {
remote-label < value> } ]
ZXR10#show pwe3 signal statistic This shows the static information of PW

signalling states.
An example of the show l2vpn brief command output is shown below.

ZXR10# show l2vpn brief
VPLS count:1 VPWS count:1
name type VCID PW AC description
inst_1 VPWS 1 1
VPLS count The number of VPLS instances
VPWS count The number of VPWS instances
name Instance name
type Instance type
PW The number of PW in an instance
AC The number of AC in an instance
description Instance description information
An example of the show l2vpn summary command output is shown below.

ZXR10(config)#show l2vpn summary
2-45


VPLS 0/8000
VPWS 1/8000
MSPW 0/8000
VLSS 0/8000
ZXR10(config)#
vpn type VPN type
configure/maximum Number of instance configured/maximum number of instance supported
An example of the show l2vpn forwordinfo command output is shown below.


100.100.1.1 20 ETH UP 81920 81920 W: vpws_zte1
PeerID The router ID of the PW peer
VcID PW vcid
PWType PW type
State PW state
Local Local label
Remote Remote label
VPNowner The instance which the PW belongs to
An example of the show pwe3 signal command output is shown below.

#show pwe3 signal
The signal information of dynamic PWs:
Hearders:C - Configured, R - Received, N - Negotiated, S - Sent,

A - AC ready, local - local label，remote - remote label,
owner-application instance of PW,sesn-the LDP session's state,
use - signal procedures succeeded and VC-LSPs formed,
2-46


Codes : ?unknown, *yes, .no
------------------------------------------------------------------
remote-pe-id vcid pw-type local remote use CRNSA type owner sesn
------------ ----- -------- ----- ------ --- ----- ---- ----- ----
1.1.1.100 1004 ethernet 81928 ? NO *..** VPWS 2 UP
remote-pe-id The peer address
vcid PW vcid
pw-type PW type
local Local tag
remote Remote tag
use Indicate whether the tag is allocated
CRNSA PW state information
type Application type
owner PW vpnid
sesn Session state
An example of the show pwe3 signal detail command output is shown below.
PW entity : < 10.10.10.32 , 100 , ethernet >
LSPs formed : NO ( remote mapping absent )
C-bits : local : NO , remote : --
negotiated : --
MTU : local : 1600 , remote : --
negotiated : --
labels : local : 81927 , remote : --
signal : Configured : YES , Received : NO
Negotiated : NO , Sent : YES
AC ready : YES
application : service-type : VPWS , instance-id: 1
remote-VCCV : CC-type : -- , CV-type : --
actual-VCCV : CC-type : -- , CV-type : --
attachment-circuit : gei-0/1/0/1
2-47

local-description : gei-0/1/0/1
remote-description : --
PW entity The peer address, vcid and PW type
LSPs formed Indicate whether it is used in data layer.
C-bits Control word information
MTU MTU value of interface on AC side
local Indicate whether the local end support CWORD
remote Indicate whether the peer signalling message showing supports CWORD.
negotiated Indicate whether negotiation result supports CWORD
Labels Tag information
local Local tag value
remote Remote tag value
signal Signalling information
Configured Indicate whether the local is configured
Received Indicate whether the peer mapping message is received.
Negotiated Indicate whether the signalling negotiation is successful
Sent Indicate whether local end sends mapping message to the peer
AC ready Indicate whether the interface binding is up (for VPWS).
application Application information
service-type Application type
instance-id VPN instance ID
LDP session LDP session state
attachment-circuit The name of binding interface (VPWS binding interface)
local-description Local interface description (interface name)
remote-description Remote interface description
2-48

2.5.5 VPWS Configuration Examples

2.5.5.1 VPWS Configuration Example One
The network topology of an L2VPN VPWS ethernet PW configuration example is shown
in Figure 2-13.
Figure 2-13 Network Structure of L2VPN VPWS Ethernet PW Configuration
1. Configure interface addresses so that PE1 interconnects to PE2.
2. Configure loopback interfaces as the LDP Router-IDs.
3. Configure OSPF to advertise the loopback interface addresses.
4. Configure an LDP instance. It is unnecessary to establish a target-session on the
direct-connected link.
5. Configure an L2VPN instance.
PE1(config)#interface fei-0/1/0/1
PE1(config-if)#exit
PE1(config-if)#exit
PE1(config-ospfv2)#interface fei-0/1/0/1
PE1(config-ospfv2-if)#exit
PE1(config-ldp)#interface fei-0/1/0/1
2-49

PE1(config)#vpws vpws_zte1
PE1(config-vpws)#sdu sdu1
PE1(config-vpws-sdu)#neighbour 100.100.1.2 20
PE1(config-vpws-sdu-pw)#control-word unused
PE1(config-vpws-sdu-pw)#signal dynamic
PE1(config-vpws-sdu-pw)#tunnel-policy auto
PE1(config-vpws-sdu-pw)#exit
PE1(config-vpws-sdu)#exit
PE1(config-vpws)#sac fei-0/1/0/2
PE1(config-vpws-sac)#service-define ethernet
PE1(config-vpws-sac-eth)#encapsulation raw
PE1(config-vpws-sac-eth)#exit
PE1(config-vpws-sac)#exit
PE1(config-vpws)#exit
PE2(config-if)#exit
PE2(config-if)#exit
2-50

PE2(config-vpws-sac)#service-define ethernet
PE2(config-vpws-sac-eth)#encapsulation raw
PE2(config-vpws-sac-eth)#exit
After the configuration, a VPWS PW can be established successfully. The following
information shows the result of configuration verification.
PE2(config)#show l2vpn forwardinfo detail
Local interface:[VPLS vpls_zte2]
MPLS VC type is ETH, Connection mode: HUB
Destination address: 100.100.1.1, VCID: 40, VC status: DOWN
Create time: 00:15:11 Last status change time: 00:15:11
Signaling protocol: LDP, peer 100.100.1.1:0,DOWN
MPLS VC labels: local -, remote -


100.100.1.1 40 ETH H DOWN - - L: vpws_zte1
PE2(config)#show l2vpn summary

VPLS 0/8000
VPWS 1/8000
MSPW 0/8000
VLSS 0/8000
2.5.5.2 VPWS Configuration Example Two
The network topology of an L2VPN VPWS IP heterogeneous PW configuration example
is shown in Figure 2-14.
2-51

Figure 2-14 Network Structure of L2VPN VPWS IP Heterogeneous PW Configuration
1. Configure interface addresses so that PE1 interconnects to PE2.
2. Configure loopback interfaces as the LDP Router-IDs.
3. Configure OSPF to advertise the loopback interface addresses.
4. Configure an LDP instance. It is unnecessary to establish a target-session on the
direct-connected link.
5. Configure an L2VPN instance.
PE1(config-if)#exit
PE1(config-if)#exit
2-52

PE1(config-vpws-sac)#inter-networking ip
PE1(config-vpws-sac-iwf-ip)#exit
PE2(config-if)#exit
PE2(config-if)#exit
PE2(config-vpws-sac)#inter-networking ip
PE2(config-vpws-sac-iwf-ip)#exit
2-53

After the configuration, a VPWS PW can be established successfully. The following
information shows the result of configuration verification.
PE2(config)#show l2vpn forwardinfo detail
Local interface:[VPLS vpls_zte2]
MPLS VC type is ETH, Connection mode: HUB
Destination address: 100.100.1.1, VCID: 40, VC status: DOWN
Create time: 00:15:11 Last status change time: 00:15:11
Signaling protocol: LDP, peer 100.100.1.1:0,DOWN
MPLS VC labels: local -, remote -


100.100.1.1 40 ETH H DOWN - - L: vpws_zte2
PE2(config)#show l2vpn summary

VPLS 0/8000
VPWS 1/8000
MSPW 0/8000
VLSS 0/8000
2.5.6 VPWS Fault Handling

Take the topology shown in Figure 2-15 as an example to describe how to handle a VPWS
fault.
2-54

Figure 2-15 Network Topology of a VPWS Fault

Symptom: There are local label and remote label, but the device cannot create a PW
between local device and remote device
Fault analysis: VPWS needs to negotiate the MTU value of an AC. If MTU values of both
ends AC of VPWS are not matched PW negotiation cannot be successful. Check if the
parameters of both ends of PWE3 are same. If MTU values are not same, modify the MTU
value of interface on AC side.

The flow to handle a VPWS fault is shown in Figure 2-16.
2-55

Figure 2-16 Flow to Handle a VPWS Fault

The procedure to handle a VPWS fault is described below.
1. Check whether the states of links and interfaces are normal.
2. Check whether the MTU of ACs at both ends are consistent. If not, modify them to be
consistent.
3. Use the show pwe3 signal vcid < number> detail command to check the result of PW
negotiation. Use the show l2vpn forwardinfo vpnname test command to check whether
the PW is established successfully.
2.6 VPWS Heterogeneous Function Configuration

2.6.1 VPWS Heterogeneous Function Overview
To meet the IP and bandwidth development requirements of the mobile network, it is
an inevitable trend to convert mobile Backhual to IP Radio Access Network (RAN). The
2-56

procedure to reconstruct a mobile Backhual network to an IP network is to upgrade the

primary Synchronous Digital Hierarchy (SDH) and ATM to IP RAN. During this upgrading
procedure, the VPWS heterogeneous function provides a low-cost solution.
The VPWS heterogeneous function supports multiple types of link layer protocol accesses:
Ethernet, Point to Point Protocol (PPP), FR, High-level Data Link Control (HDLC) and ATM.
At present, ZXR10 M6000 supports Ethernet and PPP accesses.
2.6.2 VPWS Heterogeneous Function Principle

l Heterogeneous type
According to the PW type, VPWS heterogeneous function can be classified into
IP heterogeneous function and PPP heterogeneous function. At present, the IP
heterogeneous function is accomplished on ZXR10 M6000. So, the following topics
describe the IP heterogeneous function.
l Heterogeneous mode
According to the heterogeneous awareness, the heterogeneous function can

be classified into bilateral-mode heterogeneous function and unilateral-mode
heterogeneous function.
In the bilateral mode, the two PE devices of a PW need to be aware of the
heterogeneity. That is to say, the PE devices need to do heterogeneous operations
for the packets or terminate the local packets.
In the unilateral mode, only one of the PE devices of a PW needs to be aware of the
heterogeneity. The other PE device is not aware of the heterogeneity and it forwards
the packets according to the normal VPN forwarding flow.
In this manual, the heterogeneous function is described in the heterogeneous types instead
of the heterogeneous modes.
2.6.3 Configuring the VPWS Heterogeneous Function

To configure the VPWS heterogeneous function on ZXR10 M6000, perform the following
steps.
1 ZXR10(config-vpws-sac)#inter-networking ip This configures the IP

heterogeneous function.
2 ZXR10(config-vpws-sac-iwf-ip)#local-ce mac < xxxx.xxxx.xxxx> This configures the MAC address of

a local CE.
3 ZXR10(config-PPP-if)#PPP-IPCP Proxy < ip-address> This configures the PPP IP Control

Protocol (IPCP) proxy function.
2-57

< xxxx.xxxx.xxxx> The MAC address of a local CE
< ip-address> To accomplish PPP access of the VPWS heterogeneous function, it is

necessary to configure the IP address of a remote CE. The remote CE
and the local CE negotiate IPCP.
2.6.4 VPWS Heterogeneous Function Maintenance

ZXR10 M6000 provides the following command to maintain the heterogeneous function.
Command Function
ZXR10#show pwe3 signal vcid < vcid> detail This shows the states of the PWs.
An example of the show pwe3 signal vcid 3 detail command output is shown below.
ZXR10#show pwe3 signal vcid 3 detail
PW entity : <192.168.1.100> , 10 , ethernet
LSPs formed : NO ( LDP session absent )
C-bits : local : NO , remote : ??
negotiated : ??
MTU : local : 1500 , remote : ??
negotiated : ??
labels : local : 81920 , remote : ??
signal : Configured : YES , Received : NO
Negotiated : NO , Sent : NO
AC ready : YES
application : service-type : MSPW , instance-id: 1
remote-VCCV : CC-type : ?? , CV-type : ??
actual-VCCV : CC-type : ?? , CV-type : ??
LDP session : The LDP session's state is NON, please check it.
2-58

2.6.5 VPWS Heterogeneous Function Configuration Example

It is required to support VPLS interconnection through different types of mediums. As
shown in Figure 2-17, POS interfaces are connected to GE interfaces through VPLS.
Figure 2-17 VPWS Heterogeneous Function Configuration Example
1. Configure routes between PE1 and PE2.
2. Establish LDP neighbor relationship between PE1 and PE2.
3. Enable MPLS L2 VPN on PE1 and PE2. Create a PW. Configure a VPLS instance
and configure the related remote member.
4. On PE1, the POS interface works as an AC to connect to the VPLS instance. The GE
interface on the PE is connected to a VPLS instance.
The configuration of CE1:
ZXR10(config)#interface pos3-0/5/0/1
ZXR10(config-if)#ip address 100.1.1.1 255.255.255.0
ZXR10(config-if)#exit
The configuration of PE1:

ZXR10(config)#interface loopback1
ZXR10(config)#interface gei-0/5/0/3
ZXR10(config)#router isis
ZXR10(config-isis)#area 49.0172
ZXR10(config-isis)#system-id 0020.0096.0001
ZXR10(config-isis)#interface xgei-0/5/0/3
ZXR10(config-isis-if)#ip router isis
ZXR10(config-isis-if)#end
ZXR10(config)#mpls ldp instance 1
ZXR10(config-ldp)#router-id loopback1
ZXR10(config-ldp)#interface xgei-0/5/1/1
2-59

ZXR10(config-ldp-if)#exit
ZXR10(config-ldp)#exit
ZXR10(config)#mpls l2vpn enable
ZXR10(config)#sdu sdu1
ZXR10(config)#vpws yigou
ZXR10(config-vpws)#sac pos3-0/7/1/1
ZXR10(config-vpws-sac)#inter-networking ip
ZXR10(config-vpws-sac-iwf-ip)#exit
ZXR10(config-vpws-sac)#exit
ZXR10(config-vpws)#sdu sdu1
ZXR10(config-vpws-sdu)#neighbour 1.1.1.50 100
ZXR10(config-vpws-sdu-pw)#exit
ZXR10(config-vpws-sdu)#exit
ZXR10(config-vpws)#exit
ZXR10(config)#interface pos3-0/7/1/1
ZXR10(config-if)#no shut
ZXR10(config)#ppp
ZXR10(config-ppp)#interface pos3-0/7/1/1
ZXR10(config-ppp-if)#ppp ipcp proxy-address 100.1.1.2
/*Configure PPP proxy so that PPP routes will be generated on CE1*/
ZXR10(config-ppp-if)#end
ZXR10(config)#interface loopback1
ZXR10(config)#router isis
ZXR10(config-isis)#area 49.0172
ZXR10(config-isis)#system-id 0020.0096.0002
ZXR10(config-isis)#interface gei-0/5/0/3
ZXR10(config-isis-if)#ip router isis
ZXR10(config-isis-if)#end
ZXR10(config)#mpls ldp instance 1
ZXR10(config-ldp)#router-id loopback1
ZXR10(config-ldp)#interface gei-0/5/0/3
ZXR10(config-ldp-if)#exit
ZXR10(config-ldp)#exit
ZXR10(config)#mpls l2vpn enable
ZXR10(config)#sdu sdu1
ZXR10(config)#vpws yigou
ZXR10(config-vpws)#sac gei-0/1/1/8
2-60

ZXR10(config-vpws-sac)#inter-networking ip
ZXR10(config-vpws-sac-iwf-ip)#local-ce mac 0000.2dd4.4aeb
/*This MAC address is the one of CE2*/
ZXR10(config-vpws-sac-iwf-ip)#exit
ZXR10(config-vpws-sac)#exit
ZXR10(config-vpws)#sdu sdu1
ZXR10(config-vpws-sdu)#neighbour 1.1.1.46 100
ZXR10(config-vpws-sdu-pw)#exit
ZXR10(config-vpws-sdu)#exit
ZXR10(config-vpws)#exit
After the configuration, the VPWS PW is Up. CE1 can ping CE2 (100.1.1.2) successfully.
CE1#show ip for rout ppp
IPv4 Routing Table:
*> 1100.1.1.2/32 100.1.1.1 pos3-0/5/0/1 ppp 0 0
PE1#show pwe3 signal vcid 100 detail

PW entity : < 1.1.1.50 , 100 , IP >

LSPs formed : YES
negotiated : NO
negotiated : 1500
AC ready : YES
application : service-type : VPWS , instance-id: 1
2-61


CE1#ping 100.1.1.2
!!!!!
2.6.6 VPWS Heterogeneouse Function Fault Handling

Take the topology shown in Figure 2-18 as an example to describe how to handle a VPWS
heterogeneouse function fault.
Figure 2-18 Network Topology of a VPWS Heterogeneouse Function Fault

Symptom: CE1 cannot ping CE2 successfully.
Fault analysis: The PW is not established successfully or the PW is in Down state.
1. Check whether a peer is configured when the VPWS instance is configured. If the
peer is not configured, the connection cannot be established successfully.
2. If the peer has been configured, check whether the VCIDs and the PW types are the
same. If not, configure the VCIDs and the PW types correctly.
3. If the VCIDs and the PW types are the same, check whether LDP neighbor relationship
is established properly. If LDP neighbor relationship is not established properly, the
PW cannot be established successfully. Check whether IGP neighbor relationship is
established. Make sure that the transport addresses can be pinged successfully from
each other (by default, the transport addresses are the Router-IDs).
4. If LDP neighbor relationship is established properly but the PW is not Up, check
whether labels are distributed for the destination Forwarding Equivalence Class (FEC)
in LDP and whether inuse tags are made. Meanwhile, check LDP label distribution
and label filtering policies. Make sure that LDP can distribute labels for the destination
FEC correctly and make inuse tags.
5. Check whether the POS interface that works as a VPWS AC is an IP heterogeneouse
interface, and whether PPP proxy is configured on the POS interface.
6. Check whether the AC interface on PE2 is an IP heterogeneouse interface, and
whether the MAC address of CE2 is configured.
2-62


The flow to handle a VPWS heterogeneouse function fault is shown in Figure 2-19.
Figure 2-19 Flow to Handle a VPWS Heterogeneouse Function Fault

The procedure to handle a VPWS heterogeneouse function fault is described below.
1. Check whether the link state and the interface state are correct.
2. Execute the show running-config isis command to check whether the IGP (such as
IS-IS) configuration is correct. If the configuration is correct, execute the show isis adj
command to check the IS-IS neighbor relationship until the state is Up.
3. Execute the show running-config ldp command to check whether the LDP configuration
is correct. If the configuration is correct, execute the show mpls ldp neighbor command
to check the LDP neighbor relationship until the connection is established.
2-63

4. Execute the show mpls ldp bindings command to check whether labels are distributed
correctly and whether inuse tags are made. If not, execute the show running-config ldp
command to check whether label distribution or a label filtering policy is configured.
If it is configured, check whether the rules affect label distribution. If the rules affect
label distribution, delete the rules or modify the LDP policy.
5. Execute the show running-config l2vpn command to check whether MPLS L2 VPN is
enabled, and whether related instance is configured. To ensure that two sites can ping
each other successfully, it is necessary to configure the same VCIDs and the same
PW types in the instance. After that, execute the show l2vpn forwarding vpnname
command to check whether the PW is Up.
6. Check whether the POS interface that works as a VPWS AC is an IP heterogeneouse
interface, and whether PPP proxy is configured on the POS interface.
7. Check whether the AC interface on PE2 is an IP heterogeneouse interface, and
whether the MAC address of CE2 is configured.
2.7 L2 VPN and L3 VPN Bridge Function Configuration

2.7.1 L2 VPN and L3 VPN Bridge Function Overview
When L2 VPN service needs to cross L3 VPN network, L2 VPN service needs to be end
in the middle PE device and transform L2 VPN service to L3 VPN access. In the same
way, When L3 VPN service needs to cross L2 VPN network, L3 VPN service needs to be
end in the middle PE device and transform L3 VPN service to L2 VPN access. This is the
L2 VPN and L3 VPN bridge function.
The principle of L2 VPN and L3 VPN bridge completes the transformation between L2
VPN message and L3 VPN message by configuring L2 VPN and L3 VPN bridge interface.
An L2 VPN message or an L3 VPN message are encapsulated the corresponding L3
VPN message or L2 VPN message after they are transformed in uplink through bridge
router. In downlink they are transformed as ordinary L3 or L2 message. Finally message
transmission is implemented from L2 VPN network to L3 VPN network and from L3 VPN
network to L2 VPN network. L2 VPN service message here is over VPLS, L3 VPN service
message is over MPLS.
2.7.2 Configuring L2 VPN and L3 VPN Bridge Function

L2 VPN and L3 VPN bridge configuration on ZXR10 M6000 includes the following steps.
1. Configure L2 VPN and L3 VPN on PEs. For details, please refer to VPLS configuration
and MPLS VPN configuration.
2. Create an L2 VPN or an L3 VPN bridge interface, that is, ulei interface.
3. Add an L2 VPN or an L3 VPN bridge interface to the L2 VPN and L3 VPN instance.
To configure L2 VPN and L3 VPN bridge on ZXR10 M6000, perform the following steps
2-64

1 ZXR10(config)#request interface ulei< ulei-number> This creates an L2 VPN and L3 VPN

bridge interface.
2 ZXR10(config-vpls-zte1)#sac ulei< ulei-number> This adds an L2 VPN bridge interface

into L2 VPN.
3 ZXR10(config)#interface ulei< ulei-number> This adds an L3 bridge interface into

ZXR10(config-if)#ip vrf forwarding zte2 L3 VPN instance.
2.7.3 L2, L3VPN Bridge Configuration Example

L2 VPN and L3 VPN bridge function implements L2 VPN access public network or L3 VPN
service by configuring L2 and L3 bridge interfaces, which reduces devices requirement of
traditional access mode and simplifies network structure. The typical L2 VPN and L3 VPN
bridge network is shown as Figure 2-20.
Figure 2-20 L2 VPN and L3 VPN Bridge Configuration Example
1. Configure IGP route between PE1 and PE2, PE2 and PE3 to make them interconnect.
2. Establish LDP neighbor relationship between loopback interfaces of PE1 and PE2,
and between loopback interfaces of PE2 and PE3.
3. Create a VPLS instance zte1 between PE1 and PE2, meanwhile CE1 is taken as an
AC accessing PE1.
4. Configure L3 VPN on PE2 and PE3. The Virtual Route Forwarding (VRF) instance
name is zte2.
5. Establish and configure L2 and L3 bridge interfaces on PE2: establish vlan, access
vrf zte2, access VPLS instance zte1, configure IP address.
2-65

ZXR10(config)#request interface ulei-0/1/0/1
ZXR10(config)#request interface ulei-0/1/0/2
ZXR10(config)#service-bridging virtual-links
ZXR10(config-bridge)#virtual-link ulei-0/1/0/1 ulei-0/1/0/2
ZXR10(config)#interface ulei-0/1/0/2
ZXR10(config-if)#ip vrf forwarding zte2
ZXR10(config)#vpls zte1
ZXR10(config-vpls)#sac interface ulei-0/1/0/1
ZXR10(config-vpls-sac)#exit
ZXR10(config-vpls)#exit
ZXR10(config)#interface ulei-0/1/0/2
Check the configuration result on PE2.
ZXR10(config)#show running-config-interface ulei-0/1/0/1
!<INTERFACE>
interface Ulei-0/1/0/2
index 570
ip vrf forwarding zte2
ip address 10.10.10.1 255.255.255.0
!
!</INTERFACE>
!<L2VPN>
mpls l2vpn enable
vpls zte1
!</L2VPN>
ZXR10(config)#show arp interface ulei-0/1/0/1
IP Hardware Exter Inter Sub
Address Age Address Interface VlanID VlanID Interface
-----------------------------------------------------------------
10.10.10.1 - 1010.1111.1135 ulei-0/1/0/1 1 N/A N/A
10.10.10.2 01:31:09 00e0.e1d0.5533 ulei-0/1/0/1 1 N/A gei-0/1/0/1
2-66

2.7.4 L2 VPN and L3 VPN Bridge Fault Handling

Take the topology shown in Figure 2-21 as an example to describe how to handle an L2
VPN and L3 VPN bridge fault.
Figure 2-21 Network Topology of an L2 VPN and L3 VPN Bridge Fault

Symptom: Flows cannot be forwarded properly.
Fault analysis:
1. Check whether public route is through.

2. Check whether LDP neighbor is established correctly.
3. Check whether VPLS instance state is up.
4. Check the L3 VPN state: Check whether private route is correct, and check the
BGP/Multiprotocol BGP (MP-BGP) state.
5. Check whether bridge interface configuration state is correct: IP address, bound VRF
instance and bound VPLS instance.
6. Check whether bridge interface learns the Address Resolution Protocol (ARP) address
of peer.

The flow to handle an L2 VPN and L3 VPN bridge fault is shown in Figure 2-22.
2-67

Figure 2-22 Flow to Handle an L2 VPN and L3 VPN Bridge Fault

The procedure to handle an L2 VPN and L3 VPN bridge fault is described below.
1. Check whether the states of links and interfaces are normal.

2. Use the show ip forwarding route(vrf) command to view public (private) network routes
to ensure that public (private) network routes are correct.
3. Use the show mpls ldp neighbor command to check LDP establishment state to ensure
that neighbor is established successfully.
4. Use the show l2vpn forwardinfo vpnname command to check whether the L2 VPN link
is up to ensure that link is complete.
2-68

5. Use the show ip bgp summary command to check BGP neighbor state.
6. Use the show arp interface command to check whether bridge interface learns the ARP
address of the peer.
2.8 L2 VPN FRR Configuration

2.8.1 Configuring L2 VPN FRR
To configure L2 VPN FRR on ZXR10 M6000, perform the following steps.
1. Enable L2 VPN in global configuration mode.
2. Create an SDU in global configuration mode.
3. Create a PW redundancy management group in global configuration mode.
4. Create a VPLS instance in global configuration mode and enter VPLS configuration
mode.
5. Bind the SUD to the instance in VPLS configuration mode, specify the working mode
to spoke, and enter VPLS spoke SDU configuration mode.
6. Bind the PW redundancy management group in VPLS spoke SDU configuration
mode and enter PW redundancy management configuration mode. Configure
the redundancy management group according to demands in PW redundancy
management configuration mode. Generally use the default configuration. After that,
exit from the PW redundancy management configuration mode.
7. Configure an active PW in VPLS spoke SDU configuration mode.
8. Configure a standby PW in VPLS spoke SDU configuration mode.
9. Configure mac-withdraw in VPLS spoke SDU configuration mode. When the PW is
down, mac-withdraw signalling will be triggered to accomplish updating the MACs on
the enter VPLS.
To configure L2 VPN FRR on ZXR10 M6000, perform the following steps.
Step Command function
1 ZXR10(config)#mpls l2vpn enable This enables L2 VPN FRR.
2 ZXR10(config)#sdu sdu< value> This creates an SDU.
3 ZXR10(config)#pw-redundancy-manager pw_redundancy< value> This creates a PW redundancy

management group
4 ZXR10(config)#vpls < name> [ qualified] This creates a VPLS instance and

enters VPLS configuration mode.
5 ZXR10(config-vpls)#spoke-sdu sdu< value> This binds the SUD to the instance

and specifies the working mode to
spoke.
2-69

Step Command function
6 ZXR10(config-vpls-spoke-sdu)#redundancy-manager This binds the PW redundancy

pw_redundancy< value> management group and enters
PW redundancy management
configuration mode.
ZXR10(config-vpls-spoke-sdu-rm)#exit This exits from PW redundancy

management configuration mode.
7 ZXR10(config-vpls-spoke-sdu)#neighbour < A.B.C.D> [ < VC-ID> This configures an active PW.

]
8 ZXR10(config-vpls-spoke-sdu)#neighbour < A.B.C.D> [ < VC-ID> This configures an standby PW.

] backup
9 ZXR10(config-vpls)#mac-withdraw This configures mac-withdraw.

When the PW is down, mac-withdraw
messages will be sent.
Descriptions of the parameter in Step 2, 3, 5 and 6:
< value> The number of the SDU or PW redundancy management group, in the
range of 1-55968
< name> VPLS instance name, with 32 characters at most
Descriptions of the parameter in Step 7 and 8:
< A.B.C.D> The ID of the peer router
< VC-ID> VC-ID, in the range of 1-4294967295
2.8.2 L2 VPN FRR Maintenance

The maintenance of L2 VPN FRR is similar with that of VPLS and VPWS. For details,
please refer to VPLS maintenance and VPWS maintenance.
2-70

2.8.3 L2 VPN FRR Configuration Example

The main function of L2 VPN FRR is to ensure that L2 VPN traffic can be handed over
to the standby link by establishing an active PW and a standby PW when the active link
has a fault. This ensures the reliability of L2 VPN communication. It is mainly applied to
the Spoke-PW protection between the UPEs at the user side and the NPEs at the network
side. The detection of PW ensures the fast handover of L2 VPN FRR. Meanwhile, the
MAC withdraw signaling completes the update of VPLS MACs on the entire network. A
typical VPLS FRR network topology is shown in Figure 2-23.
Figure 2-23 VPLS FRR Configuration Example
1. Configure IGP routes on UPE1, NPE2, NPE3 and NPE4 to make them ping each other
successfully. The router-ids are listed below.
Device Route-id
UPE1 1.1.1.1
NPE2 2.2.2.2
NPE3 3.3.3.3
NPE4 4.4.4.4
2. Establish LDP neighbor relationship between the four devices (UPE1, NPE2, NPE3
and NPE4).
3. Create a VPLS instance named zte among NPE2, NPE3 and NPE4. The VCID is 100,
and the PW type is ethernet-vlan. The access mode among them is hub. Meanwhile,
CE2 connects to NPE4 as an AC.
4. Associate the VPLS FRR function. Enter VPLS instance configuration mode on
UPE1 to configure the information related to the VPLS instance zte, and configure
the addresses of the active PW and the standby PW. The link between UPE1 and
2-71

NPE2 is the active PW. The link between UPE1 and NPE3 is the standby PW. CE1
connects to UPE1 as an AC.
The VPLS FRR configuration on UPE1:
UPE1(config)#mpls l2vpn enable
UPE1(config)#sdu sdu1
UPE1(config)#pw-redundancy-manager pw_redundancy1
UPE1(config)#vpls zte
UPE1(config-vpls)#spoke-sdu sdu1
UPE1(config-vpls-spoke-sdu)#redundency-manager pw_redundancy
UPE1(config-vpls-spoke-sdu-rm)#exit
UPE1(config-vpls-spoke-sdu)#neighbour 2.2.2.2 100
UPE1(config-vpls-spoke-sdu)#neighbour 3.3.3.3 100 backup
UPE1(config-vpls-spoke-sdu)#exit
UPE1(config-vpls)#mac-withdraw
UPE1(config-vpls)#exit
The VPLS FRR configuration on NPE2:

NPE2(config)#mpls l2vpn enable
NPE2(config)#sdu sdu1
NPE2(config)#vpls zte
NPE2(config-vpls)#spoke-sdu sdu1
NPE2(config-vpls-spoke-sdu)#neighbor 1.1.1.1 100
NPE2(config-vpls-spoke-sdu)#exit
The VPLS FRR configuration on NPE3:

NPE3(config)#mpls l2vpn enable
NPE3(config)#sdu sdu1
NPE3(config)#vpls zte
NPE3(config-vpls-spoke-sdu)#neighbor 1.1.1.1 100
NPE3(config-vpls-spoke-sdu)#end
Check the result of the configuration on UPE1, as shown below.
UPE1#show running-config l2vpn
! <L2VPN>
mpls l2vpn enable
vpls zte
mac-withdraw
spoke-sdu sdu1
redundancy-manager pw_redundancy1
pfs-bits unused
2-72

$
neighbour 3.3.3.3 100
encapsulation raw
$
neighbour 2.2.2.2 100 backup
encapsulation raw
$
$
!
! </L2VPN>
Check the PW information on UPE1, as shown below.
UPE1#show l2vpn forwardinfo vpnname zte

Llabel - Local label, Rlabel - Remote label
PeerIP VCID PWType State Llabel Rlabel VPNowner

2.2.2.2 100 ETH S UP 81921 81921 L: zte
3.3.3.3 100 ETH S UP 81920 81920 L: zte
2.8.4 L2 VPN FRR Fault Handling

The network topology of a L2 VPN FRR fault is shown in Figure 2-24.
Figure 2-24 Network Topology of a L2 VPN FRR Fault

Symptom: When the active link is down, traffic is not handed over to the standby link
successfully.
2-73

Fault analysis: When the handover is not successful, check whether the standby link is
UP.

The flow to handle a L2 VPN FRR fault is shown in Figure 2-25.
Figure 2-25 Flow to Handle a L2 VPN FRR Fault

The procedure to handle a L2 VPN FRR fault is described below.
1. Check whether the device links are up. If the links are down, check whether this is
caused by a route fault or an LDP fault.
2. Check whether the link between NPE3 and NPE4 is up. If it is down, check whether
this is caused by a route fault or an LDP fault.
2.9 MAC Ping/MAC Trace Configuration

2.9.1 MAC Ping/MAC Trace Overview
MAC Trace and MAC Ping provides methods for performance test and error test at for at
L2 VPN layer. They can test to check the connectivity of L2 VPN layer through sending
and receiving EOAM ping messages.
2-74

EOAM function is defined in 802.3ah Draft. The EOAM function can test information at
Ethernet link layer defined by Institute of Electrical and Electronics Engineers (IEEE) 802.3.
With this function, MAC Ping and MAC Trace provides the Ping mechanism at data link
layer used to check the connectivity of L2 VPN layer. A local device sends a request
message which contains the destination MAC address. The Operation, Administration
and Maintenance (OAM) sub-layer sends out this ping request as an OAM Protocol Data
Unit (PDU). When the receiver receives this request, it will generate an OAM PDU as the
response.
2.9.2 MAC Ping/MAC Trace Principle

A network topology of MAC Trace and MAC Ping on the base of EOAM is shown in Figure
2-26.
Figure 2-26 Network Topology of MAC Ping and MAC Trace
At present, MAC Ping supports CE1 ping CE2, PE1 ping PE2 and PE1 ping CE2 The
parameters of ping command used on CE devices and PE devices are different.
Take the examples of CE1 pinging CE2 and PE1 pinging PE2 to explain the procedure.
l CE1 pinging CE2
CE1 sends a ping request of MAC layer. The request contains the out-interface and
destination MAC of the ping request message. When CE2 receives this request
message, it will send a reply message. If CE1 can receive the reply message within
a period, the link layer is through.
l PE1 pinging PE2
PE1 sends a ping request of MAC layer. The request contains the destination MAC of
the ping request message, VPLS name and peer ID. When PE2 receives this request
message, it will send a reply message. If CE1 can receive the reply message within
a period, the link layer is through.
2-75

At present, MAC Trace supports track from CE1 to CE2, from PE1 to PE2 and from PE1
to CE2.
l CE1 to CE2
CE1 sends a trace request of MAC layer. If the link is through, corresponding MAC
addresses on interfaces of CE1, PE1, PE2 and CE2 will be recorded.
l PE1 to PE2
PE1 sends a trace request of MAC layer. If the link is through, corresponding MAC
addresses on interfaces of PE1 and PE2 will be recorded.
l PE1 to CE2
PE1 sends a trace request of MAC layer. If the link is through, corresponding MAC
addresses on interfaces of PE1, PE2 and CE2 will be recorded.
2.9.3 Configuring MAC Ping/MAC Trace

2.9.3.1 Configuring MAC Ping
To configure MAC Ping on ZXR10 M6000, use the following command.
Command Function
ZXR10#mac-ping < destination-mac> { interface < out-port> | vpls < This uses a private protocol to test the
vpls-name> peer < peer-address> | vpws < vpws-name> peer < peer-address> connectivity to the destination on an
} { summary | detail} [ external-vlan < external-vlan-id> internal-vlan < Ethernet link.
internal-vlan id> | vlan < vlan-id> ] [ repeat < repeat-count> ] [ timeout
< timeout-seconds> ]
Parameter descriptions:
< destination-mac> The destination MAC address
interface < out-port> The out-interface to send a request message on a CE device
summary Listing summary MAC Ping result
detail Listing detailed MAC Ping result
repeat < repeat-count> Repeating times, in the range of 1–65535, with the default value 5
external-vlan The ID of an external VLAN, in the range of 1–4094
internal-vlan The ID of an internal VLAN, in the range of 1–4094
vlan The ID of a VLAN, in the range of 1–4094
timeout < timeout seconds> The interval of time-out, in the range of 1–20, with the default value 2
seconds
vpls < vpls-name> The VPLS name to be tested on a PE device
peer < peer-address> The remote Router-ID to be tested on a PE device
2-76

2.9.3.2 Configuring MAC Trace

To configure MAC Trace on ZXR10 M6000, use the following command.
Command Function
ZXR10#l2trace < destination-mac> { interface < out-port> | vpls < This uses a private protocol to trace the
vpls-name> peer < peer-address> | vpws < vpws-name> peer < peer-address> path to the destination on an Ethernet
} [ external-vlan < external-vlan-id> internal-vlan < internal-vlan-id> | link.
vlan < vlan-id> ]
< destination-mac> The destination MAC address
interface < out-port> The out-interface to send a request message on a CE device
vpls < vpls-name> The VPLS name to be tested on a PE device
peer < peer-address> The remote Router-ID to be tested on a PE device
external-vlan The ID of an external VLAN, in the range of 1–4094
internal-vlan The ID of an internal VLAN, in the range of 1–4094
vlan The ID of a VLAN, in the range of 1–4094
2.9.4 MAC Ping/MAC Trace Configuration Example

MAC Ping and MAC Trace are used to test the connectivity of L2 VPN. The principle is
similar with that of Ping and Trace.
As shown in Figure 2-27, PE1, P1 and PE2 are in an L2 VPN network. It is required to use
MAC Ping and MAC Trace on CE1 to test the connectivity of the link to CE2.
2-77

Figure 2-27 MAC PING and MAC PING TRACE Configuration Example
1. Use MAC Ping on CE1 to test the connectivity of the link to CE2, as shown below.
CE1#mac-ping 00d0.d0c2.7d81 interface gei-0/1/0/1 detail
sending 5,100-byte EOAM echos to 00d0.d0c2.7d81,timeout is
2 seconds.
!!!!!
SNo Input port MAC Address Output port Hostname

-------------------------------------------------------------
send 00d0.d0c2.e141 gei-0/1/0/1 CE1
receive gei-0/5/0/1 00d0.d0c2.7d81 CE2
Or:
CE1#mac-ping 00d0.d0c2.7d81 interface gei-0/1/0/1 summary
2 seconds.
!!!!!
2. Use MAC Ping on PE1 to test the connectivity of the link to CE2, as shown below.
PE1#mac-ping 00d0.d0c2.7d81 vpls zte peer 10.9.9.9 detail
2 seconds.
!!!!!
2-78

SNo Input port MAC Address Output port Hostname

-----------------------------------------------------------
send 00d0.d0a5.3251 gei-0/2/0/1 PE1
receive gei-0/5/0/1 00d0.d0c2.7d81 CE2
Or:
PE1#mac-ping 00d0.d0c2.7d81 vpls zte peer 10.9.9.9 summary
2 seconds.
!!!!!
3. Use MAC Trace on CE1 to test the connectivity of the link to CE2, as shown below.
CE1#l2trace 00d0.d0c2.7d81 interface gei_3/8
Starting L2 Trace to 00d0.d0c2.7d81
'*' - timeout, 'U' - unreachable,
CE1: gei-0/1/0/1 [00d0.d0c2.e141] ->
PE1: gei-0/2/0/1 [00d0.d0a5.3251] ->
PE2: gei-0/4/0/1 [00d0.d0ce.c801] ->
CE2: gei-0/2/0/1 [00d0.d0c2.7d81] ->

[finished]
4. Use MAC Trace on PE1 to test the connectivity of the link to CE2, as shown below.
PE1#l2trace 00d0.d0c2.7d81 vpls mac peer 10.9.9.9
Starting L2 Trace to 00d0.d0c2.7d81
'*' - timeout, 'U' - unreachable,
PE1: gei-0/2/0/1 [00d0.d0a5.3251] ->
PE2: gei-0/4/0/1 [00d0.d0ce.c801] ->
CE2: gei-0/2/0/1 [00d0.d0c2.7d81] ->

[finished]
2.9.5 MAC Ping/MAC Trace Fault Handling

A network topology of a MAC Ping/MAC Trace fault is shown in Figure 2-28.
2-79

Figure 2-28 Network Topology of a MAC Ping/MAC Trace Fault

When the mac-ping or l2trace command is used to test the connectivity, a link is not
available according to the output. This may be caused by a parameter configuration
mistake or a fault on the L2 VPN network.

The flow to handle a MAC Ping/MAC Trace fault is shown in Figure 2-29.
2-80

Figure 2-29 Flow to Handle a MAC Ping/MAC Trace Fault

The procedure to handle a MAC Ping/MAC Trace fault is described below.
1. Check whether the L2 VPN network connectivity. For the detailed method, refer to
corresponding information in MPLS L2 VPN configuration.
2. Use the mac-ping command. If there is any error in the configuration commands,
corresponding information will be printed. Check the configuration according to the
information printed.
3. Lengthen the timeout delay in the mac-ping command, for example, change the delay
to 10 seconds with the command mac-ping 00d0.d0c2.7d81 interface gei-0/1/0/1 detail
timeout 10, and then check the connectivity.
4. Configure the hops in the mac-ping command, for example, set the hops as 10 with
the command mac-ping 00d0.d0c2.7d81 interface gei-0/1/0/1 detail hops 10, and then
check the connectivity.
2-81

2.10 MC-ELAM Configuration

2.10.1 MC-ELAM Overview
To meet the requirement of service operators for MPLS L2 VPN reliability and the
requirement of end-to-end services for real time, it is necessary to introduce related
protection mechanisms for CE access, PW access and the links between PWs. For CE
access, the protection can be accomplished by connecting two CEs to the active and the
standby PE. Multi-Chassis Ethernet Link Aggregation Manager (MC-ELAM) is used to
coordinate the active and the standby PEs and to discover the status.
2.10.2 MC-ELAM Principle

According to application situations, there are to applications to connect two CEs to two
PEs. One is VPLS application, and the other is Pseudo Wire Emulation Edge-to-Edge
(PWE3) application.
l Connecting two CEs to two PEs in VPLS application
As shown in Figure 2-30, CE1 is connected to NPE1 and NPE2 through AC1 and
AC2. The state of AC1 is Active, and the state of AC2 is Standby. This improves the
network reliability and prevents the unavailability caused by loop faults or single-point
faults.
Figure 2-30 Typical Network Structure of Connecting Two CEs to Two PEs
When AC1 has a fault, NPE2 can be aware of the fault quickly and starts to negotiate
with CE1 to make AC2 be active. So the traffic from CE1 to CE2 is changed over from
AC1 to AC2 directly. Meanwhile, NPE1 or NPE2 needs to send MAC WITHDRAW
messages to other NPE devices in the same Virtual Forwarding Instance (VFI) on the
VPLS network to inform other PEs to age the invalid MAC addresses. In this way, the
traffic from CE2 to CE1 can be learnt through broadcast and be forwarded through
NPE2 correctly.
2-82

In the same way, when NPE1 has a fault, NPE2 can detect the fault through other
detection mechanisms and trigger AC link negotiation, and then it sends MAC
WITHDRAW messages to other NPE devices in the same VFI.
l Connecting two CEs to two PEs in PWE3 application
As shown in Figure 2-31, the Time Division Multiplexing (TDM) service of a Base
Transceiver Station (BTS) is connected to a Base Station Controller (BSC). The
network overlays on the MPLS L2 VPN at the core layer. The BSC is connected to
two devices. Assume that the link between the BSC a device is in Active status, and
the link between the BSC and the other device is in the Standby status. The traffic
from the BTS to the BSC and the traffic from the BSC back to BTS is carried over the
on the Active link. When a fault occurs to the Active link, the service packets from
the BSC to the BTS are changed over to the Standby link. Meanwhile, changeovers
of active and standby PWs at the access layer, the aggregation layer and the core
layer are also executed on the base of the linkage mechanism. When the active PE
has a fault, the PW changeover is executed on the base of PW FRR.
Figure 2-31 Connecting Two CEs to Two PEs in PWE3 Application
2.10.3 Configuring MC-ELAM

To configure MC-ELAM on ZXR10 M6000, perform the following steps.
1 ZXR10(config)#mc-elam-configuration This enters MC-ELAM configuration

mode from global configuration
mode.
2 ZXR10(config-mc-elam-configuration)#mc-elam < id> This creates an MC-ELAM instance

and enters MC-ELAM instance
configuration mode. Use the no
format of this command to delete an
MC-ELAM instance.
2-83

3 ZXR10(config-mc-elam-instance)#source < source-ip> This configures the source IP

address of an MC-ELAM instance.
4 ZXR10(config-mc-elam-instance)#destination < destination-ip> This configures the destination IP

address of an MC-ELAM instance.
5 ZXR10(config-mc-elam-instance)#system-priority < This configures the system priority

priority-value> of an MC-ELAM instance. Use the
no format of this command to restore
the default value. The default value
is 32768.
6 ZXR10(config-mc-elam-instance)#system-mac < value> This configures the system MAC of

an MC-ELAM instance. Use the no
format of this command to restore
is the system base MAC.
7 ZXR10(config-mc-elam-instance)#timeradvertise < This configures the interval of

advertise-interval> sending protocol packets in an
MC-ELAM instance. Use the no
is 10 (unit: 100 ms).
8 ZXR10(config-mc-elam-instance)#detect-multiplier < multiplier> This configures the multiplier of

protocol packet time-out interval in
an MC-ELAM instance. Use the no
is 5.
9 ZXR10(config-mc-elam-instance)#restore { revertive < This configures the restoring mode

holdoff-time> | immediately | non-revertive} and restoring time in an MC-ELAM
instance. Use the no format of this
command to restore the default
value. The default value is restoring
immediately.
10 ZXR10(config-mc-elam-instance)#track < track-name> { link-type This configures the linkage

| peer-type | pw-type} relationship between an MC-ELAM
instance and the SAMGR module.
Use the no format of this command
to release the linkage relationship.
2-84

11 ZXR10(config-mc-elam-instance)#bind smartgroup< id> [ mode This binds an MC-ELAM instance

{ auto | master | slave } ] to a smartgroup interfaces and
configures the negotiation mode.
Use the no format of this command
to delete the binding.
< id> MC-ELAM instance ID, in the range of 1-64, such as mc-elam 1
< source-ip> The source IP address of an MC-ELAM instance
< destination-ip> The destination IP address of an MC-ELAM instance
< priority-value> System priority of an MC-ELAM instance, in the range of 1-65535,

defaulting to 32768
< value> System MAC of an MC-ELAM instance, in the range of 0-FFFFFFFFFFFF,

defaulting to the system base MAC
< advertise-interval> The interval of sending protocol packets in an MC-ELAM instance, in the
range of 5-100, defaulting to 10, in the unit of 100 ms
2-85

< multiplier> The multiplier of protocol packet time-out interval in an MC-ELAM instance,
in the range of 3-180, defaulting to 5
revertive Reverting mode
< holdoff-time> Hold-off time, in the range of 1-120, in the unit of second
immediately Reverting immediately
non-revertive Not reverting
< track-name> The name of a track object to be tracked
link-type Handling according to link type
peer-type Handling according to peer type
pw-type Handling according to public PW type
< id> The ID of a smartgroup interface to be bound to, in the range of 1-64
auto Automatic negotiation mode
master Master mode
slave Slave mode
2.10.4 MC-ELAM Maintenance

ZXR10 M6000 provides the following command to maintain MC-ELAM.
Command Function
ZXR10(config-mc-elam-instance)#show mc-elam { all | brief| id } This shows the MC-ELAM information.
all Shows all information related to MC-ELAM
2-86

brief Only shows Master and Slave status of MC-ELAM and bound smartgroup
interface
id Shows the information of a specified MC-ELAM instance
An example of the show mc-elam all command output is shown below.

ZXR10#show mc-elam all
------------------------------------------------------
mcelam-instance-id :64
destination_ip :1.1.1.2
source_ip :0.0.0.0
system_priority :32768
system_mac :00e3.d021.0203
virtual_mcelam_priority :0
virtual_mcelam_smac :0000.0000.0000
sm_state :MCELAM_LOGICAL_NODE
smartgroup_id :1
bind_mode :MCELAM_AUTO_MODE
actor_mcelam_role :SLAVE
actor_lacp_role :SLAVE
actor_sg_admin_state :UP
actor_sg_protocol_state :DOWN
actor_revertive_mode :MCELAM_IMMEDIATELY_MODE
revertive_time :0
actor_adver_int :10
actor_detect_multiplier :5
actor_pwfault :0
partner_mcelam_role :SLAVE
partner_lacp_role :SLAVE
partner_sg_protocol_state:DOWN
partner_adver_int :0
partner_detect_multiplier:0
partner_pwfault :0
Output descriptions
Output Item Description
mcelam-instance-id MC-ELAM instance ID
destination_ip The destination IP address of the MC-ELAM instance
source_ip The source IP address of the MC-ELAM instance
2-87

Output Item Description
system_priority The system priority of the MC-ELAM instance
system_mac The system MAC of the MC-ELAM instance
virtual_mcelam_priority The virtual system priority of the MC-ELAM instance
virtual_mcelam_smac The virtual system MAC of the MC-ELAM instance
sm_state The status of the status machine in the MC-ELAM instance
smartgroup_id The ID of the smartgroup interface bound to the MC-ELAM instance
bind_mode The mode to bind the MC-ELAM instance to the smartgroup interface
actor_mcelam_role The role of the local MC-ELAM instance
actor_lacp_role The role of the smartgroup interface bound to the local MC-ELAM instance
actor_sg_admin_state The administration state of the smartgroup interface bound to the local
MC-ELAM instance
actor_sg_protocol_state The protocol state of the smartgroup interface bound to the local MC-ELAM
instance
actor_revertive_mode The reverting mode of the local MC-ELAM instance
revertive_time The reverting time of the local MC-ELAM instance
actor_adver_int The interval of sending packets in the local MC-ELAM instance
actor_detect_multiplier The multiplier of the packet time-out interval in the local MC-ELAM instance
actor_pwfault Whether the PW errors in the local MC-ELAM instance
partner_mcelam_role The role of the peer MC-ELAM instance
partner_lacp_role The role of the smartgroup interface bound to the peer MC-ELAM instance
partner_sg_protocol_state The protocol state of the smartgroup interface bound to the peer MC-ELAM
instance
partner_adver_int The interval of sending packets in the peer MC-ELAM instance
partner_detect_multiplier The multiplier of the packet time-out interval in the peer MC-ELAM instance
partner_pwfault Whether the PW errors in the peer MC-ELAM instance
2.10.5 MC-ELAM Configuration Example

As shown in Figure 2-32, the interfaces gei-0/3/0/1, gei-0/3/0/2, gei-0/3/0/3 and gei-0/3/0/4
on the CE are in smartgroup1. It is required to add the interfaces gei-0/3/0/1 and gei-0/3/0/2
on the two PE devices to smartgroup2.
2-88

Figure 2-32 MC-ELAM Configuration Example
1. Configure an MC-ELAM instance.
2. Configure the source and the destination IP addresses of the MC-ELAM instance.
3. Configure the MC-ELAM instance to bind to a smmartgroup interface in automatic
mode.
4. Configure the reverting mode of the MC-ELAM instance
The configuration of the CE:
CE(config)#mc-elam-configuration
CE(config-mc-elam-configuration)#mc-elam 1
CE(config-mc-elam-instance)#bind smartgroup 1 mode auto
CE(config-mc-elam-instance)#restore immediately
PE1(config)#mc-elam-configuration
PE1(config-mc-elam-configuration)#mc-elam 1
PE1(config-mc-elam-instance)#bind smartgroup 1 mode auto
PE1(config-mc-elam-instance)#restore immediately
PE2(config)#mc-elam-configuration
PE2(config-mc-elam-configuration)#mc-elam 1
PE2(config-mc-elam-instance)#bind smartgroup 1 mode auto
PE2(config-mc-elam-instance)#restore immediately
2-89

Execute the show mc-elam 1 command to check the configuration result on the CE, as
shown below.
CE(config-mc-elam-instance)#show mc-elam 1
------------------------------------------------------
source_ip :0.0.0.0
system_mac :0009.9100.0106
virtual_mcelam_priority
smartgroup_id :1
actor_sg_protocol_state :UP
revertive_time :0
actor_adver_int :10
actor_pwfault :0
partner_sg_protocol_state:DOWN
partner_detect_multiplier:0
partner_pwfault :0
Use the show mc-elam 1 command to check the configuration result on PE1, as shown
below.
PE1(config-mc-elam-instance)#show mc-elam 1
------------------------------------------------------
source_ip :0.0.0.0
system_mac :0000.0100.9902
2-90

virtual_mcelam_priority :0
smartgroup_id :1
actor_sg_protocol_state :UP
revertive_time :0
actor_adver_int :10
actor_pwfault :0
partner_sg_protocol_state :DOWN
partner_detect_multiplier :0
partner_pwfault :0
2.10.6 MC-ELAM Fault Handling

The network topology of an MC-ELAM fault is shown in Figure 2-33.
Figure 2-33 Network Topology of an MC-ELAM Fault
2-91


Common MC-ELAM faults are that Master and Slave status cannot handed over
successfully. The possible causes are listed below.
1. The smartgroup interfaces on the CE and the PEs are not Up.
2. The mode to bind the smartgroup interfaces is not correct.
3. The source and the destination IP addresses are not correct.

The flow to handle an MC-ELAM fault is shown in Figure 2-34.
Figure 2-34 Flow to Handle an MC-ELAM Fault

The procedure to handle an MC-ELAM fault is described below.
1. Execute the show ip interface brief command to check the status of the ports, as shown
below.
CE(config)#show ip interface brief
Interface IP-Address Mask AdminStatus PhyStatus Protocol
fei-0/1/0/1 unassigned unassigned up up up
2-92


vlan2 2.1.1.1 255.255.255.0 up up up
smartgroup1 unassigned unassigned up up up
2. Execute the show running-config mc-elam command to check whether the mode to
bind smartgroup interfaces are correct.
CE(config)#show running-config mc-elam
! <MC_ELAM>
mc-elam-configuration
mc-elam 1
timeradvertise 100
system-priority 144
restore revertive 120
destination 1.1.1.2
system-mac 0000.0000.0006
bind smartgroup 1 mode auto
$
! </MC_ELAM>
3. Execute the show running-config mc-elam command to check whether the source and
the destination IP addresses are correct, as shown below.
CE(config-mc-elam-instance)#show running-config mc-elam
! <MC_ELAM>
mc-elam-configuration
mc-elam 1
timeradvertise 100
system-priority 144
restore revertive 120
source 1.1.1.1
destination 1.1.1.2
system-mac 0000.0000.0006
bind smartgroup 1 mode auto
$
! </MC_ELAM>
2-93

This page intentionally left blank.
2-94

Chapter 3
MPLS L3 VPN Configuration
Table of Contents
MPLS VPN Basic Function Configuration ...................................................................3-1
MPLS VPN Route Aggregation Configuration ...........................................................3-37
VPN Route Restriction and Alarm.............................................................................3-46
L3 VPN FRR Configuration ......................................................................................3-55
MPLS VPN Load Balancing Configuration ................................................................3-62
3.1 MPLS VPN Basic Function Configuration

3.1.1 MPLS L3VPN Overview
MPLS L3 VPN is a kind of IP VPN based on MPLS technology. It is also called L3VPN,
which applies MPLS technology to routers and switches. MPLS VPN simplifies the route
selection mode of core routers, and it realizes IP virtual private network by means of the
label switching of conventional routing technology.
MPLS VPN can be used to construct broadband Intranet and Extranet, which can satisfy
the requirements of many services cleverly.
MPLS VPN can utilize the powerful transmission capability of a public backbone network
to reduce the construction costs of the Intranet, and greatly improve the operation and
management flexibility of user networks. Meanwhile, it meets the user requirements for
data transmission security, real time and broad band, convenience.
In an IP-based network, MPLS has many advantages,
1. Reduce cost
MPLS simplifies the integration technology of ATM and IP. It efficiently combines the
L2 and L3 technologies. Therefore, the cost is reduced and the investment is saved
at earlier stages.
2. Improve resource utilization rate
Since label switching is used in network, the IP addresses used by users in their LAN
can be repeated. In this way, IP resource utilization rate is improved.
3. Improve network speed
Since label switching is used, the time for address search in each hop process is
shortened. In this way, the time of data transmission time is reduced in network, and
the network speed is improved.
4. Improve flexibility and expansibility
3-1

Since MPLS uses AnyToAny connection, the network flexibility and expansibility are
improved. With respect to the flexibility, special control policy can be customized to
meet special requirements of different users to realize value-added services. The
expansibility covers the following two points:
l More VPNs are contained by a network.
l Easy user expansion in the same VPN.
5. Convenience
MPLS is widely used in operator networks. It bring more convenience to enterprise
users establish global VPN.
6. Improve transmission security

MPLS serves as a channel mechanism to implement transparent packet transmission.
MPLS Link State Packets (LSP)s have high reliability and security, similar to frame
relay and ATM Virtual Channel Connection (VCC).
7. Enhance service integration capability
A network can support the services integrating data, audio and video.
8. MPLS QoS guarantee
The related standards and drafts drawn by Internet Engineering Task Force (IETF) for
Border Gateway Protocol (BGP)/MPLS VPN:
l Request For Comments (RFC) 4364BGP/MPLS IP Virtual Private Networks
l RFC 4760 Multiprotocol Extensions for BGP-4
l RFC 2547, BGP/MPLS VPN
l Draft RFC 2547bis, BGP/MPLS VPN
l RFC 2283, multi-protocol extension BGP4
3.1.1.1 MPLS L3VPN Related Terms

A BGP/MPLS VPN network system covers the following network devices.
l PE
A PE refers to a router connected to a CE in a customer site in an operator network.
The PE router supports VPN and labeling function (the labeling function can be
provided by RSVP, LDP or Constraint based Routing Label Distribution Protocol
(CRLDP)).
In a single VPN, PE routers are connected by tunnel. The tunnel can be a MPLS LSP
tunnel or a LDP tunnel.
l Provider (P)
Here, “P” refers a router in the core of an operator network, which does not connect
to any router in any customer site, but is a part of MPLS L3 VPN tunnel. “P” supports
MPLS LSP or LDP function, but it does not need to support VPN.
l CE
3-2

CE refers to a router or switch connected to an operator network in a customer site.

Normally, IP router act as CE device.
VPN function is provided by PE routers, while P and CE routers do not have special
requirements for VPN configuration.
3.1.1.2 VPN-IPv4 Address and RD

Since L3 VPN may be connected to private networks through Internet and these private
networks can either use public or private addresses, the addresses used by different
private networks may be repeated when private networks use private addresses.
To avoid the repetition of private addresses, public addresses can be used by network
devices to replace private addresses. A solution is provided in RFC2547bis that uses an
existent private network ID to generate a definite new address.
The new address is a part of VPN-IPv4 address family, and it also is a BGP address family
of the MP-BGP protocol. In a VPN-IPv4 address, there is a value used to differentiate
different VPNs, called Route Distinguisher (RD).
The format of a VPN-IPv4 address is an eight-byte RD plus a four-byte IP address. RD is
the eight-byte value used for VPN differentiation. An RD consists of the following fields:
l Type field (two bytes): It determines the length of the other fields.
à If the value of the type field is 0, Administrator (ADM) field covers four bytes and
the Assignment Number (AN) domain covers two bytes.
à If the value of the type field is 1, ADM field covers two bytes and the Assignment
Number (AN) field covers four bytes.
l ADM field: It identifies an administration assignment number
à If the value of the type field is 0, ADM field contains an IPv4 address. RFC2547bis
recommends to use router IP address (this address is normally configured as
router ID). Router IP address is a public address.
à If the type domain is 1, the administrator domain contains an Autonomous System

(AS) ID. RFC2547bis recommends a public AS ID allocated by Internet Assigned
Numbers Authority (IANA) be used (it is much better that the AS ID of the ISP or
customer itself is used).
l AN field: The number assigned by a network operator
à If the type field is 0, AN field covers two bytes.

à If the type field is 1, AN field covers four bytes.
The RD is only used between PEs and CEs to differentiate IPv4 addresses of different
VPNs. The ingress generates an RD and converts the received IPv4 route of the CE into
a VPN-IPv4 address. Before advertising the route to the CE, the egress PE converts the
VPN-IPv4 route into an IPv4 route.
3-3

3.1.1.3 MPLS VPN Principle

MPLS VPN uses L3 technology. Every VPN has its own VPN-ID. Every VPN user can only
communicate with the members belonging to the same VPN, and only VPN members can
enter the VPN.
In MPLS VPN, the Service Provider (SP) allocates an RD to every VPN. The RD is unique
in SP network.
Forwarding table contains a unique address, called VPN-IP address, which is formed
through the connection of the RD and user IP address. The VPN-IP address is unique
in the network. The address table is stored in the forwarding table.
BGP is a routing information distribution protocol, which uses multi-protocol extension
and common attributes to define VPN connectivity. In MPLS VPN, BGP only advertises
messages to the members in the same VPN, and provides basic security by means of
traffic split.
Data is forwarded by using LSP. The LSP defines a special path that cannot be changed,
to guarantee the security. Such a label-based mode can provide confidentiality like frame
relay and ATM. The SP associates a special VPN to an interface, and packet forwarding
is decided by ingress labels.
VPN forwarding table contains a label that corresponds to the VPN-IP address. The label
is used to send data to the corresponding destination. Since the label replaces the IP
address, user can keep its own address structure. The data can be transmitted without
Network Address Translation (NAT). According to the data ingress, the corresponding
router will select a special VPN forwarding table that only contains a valid destination
address in VPN. Router selects a specified VPN forwarding table according to the ingress.
The VPN forwarding table contains the valid destination addresses only.
CE advertises routing information on the user's network to the PE by means of static route,
default route, routing protocols RIP, OSPF, IS-IS or BGP.
CE sends the routing information to PE by static route, default router or routing
protocol, such as Routing Information Protocol (RIP), OSPF and Intermediate
System-to-Intermediate System (IS-IS).
Meanwhile extended multi-protocol BGP is used between PEs to transmit VPN-IP

information and the corresponding labels (VPN label, called inner label hereinafter).
The conventional IGP is used between PE and P to learn the routing information, and the
LDP is used to bind the routing information to label (a label on the backbone network,
called outer label hereinafter).
In this way, the basic network topology and routing information among CE, PE and P are
already formed. Thus, the PE router has the routing information of backbone network and
every VPN.
When CE user data belonging to some VPN enters the network, the system can identify to
which VPN the CE belongs on the interface of CE that connects to PE, and will further read
the next-hop address information in the routing table of the VPN. In addition, the forwarded
3-4

packets will be marked with a VPN label (inner label). In this case, the obtained next-hop
address is the address of a PE that is the peer of this PE.
To reach the destination PE, routing information of backbone network is read from the
source PE , thus to obtain the address of the next P router. Meanwhile, the forwarded user
packets are marked with a backbone network label (outer label).
On backbone network, all the P routers locating behind the source PE read the outer label
to determine the next hop. Therefore, the simple label switching is performed in backbone
network only.
When the packet reaches the last P router before arriving at the destination PE, the outer
label will be removed. After the packet reaches the destination PE, the PE will read the
inner label, find the next-hop CE in the corresponding VPN routing table and send the
packet to the related interface, and then transmit the packet to the CE network of the VPN.
3.1.2 Configuring MPLS L3VPN

3.1.2.1 Creating VRF on a PE
A VRF table is created for each VPN on a PE. VRF only saves the route information related
to this VPN. VPN is independent, which has its own interface, routing and label tables,
route protocol and so on.
To create VRF on ZXR10 M6000, perform the following steps.
1 ZXR10(config)#ip vrf < vrf-name> This configures a VPN instance.
2 ZXR10(config-vrf)#rd < route-distinguisher> This defines VRF RD.
3 ZXR10(config-vrf)#address-family { ipv4| ipv6} This activates IPv4 or IPv6 address

family.
4 ZXR10(config-vrf-af)#route-target [ import | export | both] < This creates route-target extension

extended-community> community attribute relating to VRF.
5 ZXR10(config)#interface < interface-name> This enters interface configuration

mode.
6 ZXR10(config-if)#ip vrf forwarding < vrf-name> This associates interface to VRF.

Delete the existent IP address of the
interface before using this command.
7 ZXR10(config-if)#ip address < ip-address> < netmask> This configures interface address.
Descriptions of the parameters used by step 1, 2, 3 and 4 are shown below.
< vrf-name> VRF name, 1 - 32 characters. The name is only valid locally, which is used
for binding an interface to the VPN.
3-5

< route-distinguisher> VRF RD, there are two formats, <1-65535>:<0--4294967295> or

A.B.C.D:<0-65535>.
{ ipv4| ipv6} Activate IPv4 or IPv6 address family.
import Import the route to VRF according to route-target extension community

attribute
export Export the VRF route with route-target extension community attribute
both It is equal to enable import and export at the same time.
< extended-community> The route-target extension community attribute, there are

three formats, 1-65535 :0-4294967295 or A.B.C.D:0-65535 or
<1-65535>.<0-65535>:<0-65535>
3.1.2.2 Configuring Static Route Protocol Between a CE and a PE

In order to run static route protocol between a CE and a PE, a static route pointing to a CE
needs to be configured on a PE, and the static route needs to be distributed to BGP.
To run static route protocol between a CE and a PE on ZXR10 M6000, perform the following
steps.
1 ZXR10(config)#ip route vrf < vrf-name> < prefix of destination This configures a static route pointing
ipaddress> < net-mask> { < forwarding-router's-address> [ globle] | < to CE on PE.
interface-name> [ < forwarding-router's-address> ] } [ < distance-metric> It is required to specify a VRF to
] [ metric < metric-number> ] [ bfd enable] which this static route belongs.
2 ZXR10(config)#router bgp < as-number> This enters BGP route configuration

mode.
3 ZXR10(config)#address-family ipv4 vrf < vrf-name> This enters VRF address family
configuration mode.
4 ZXR10(config)#redistribute static This redistributes the static route.
Example
As shown in Figure 3-1, static routes run between CE1 and PE1.
3-6

Figure 3-1 Running Static Route Protocol between CE and PE
Configure addresses in the same segment on the direct-connected interfaces of CE1 and
PE1. Configure a static route on PE1.
Configuration on CE1:
CE1(config)#interface fei-0/1/0/1
CE1(config-if)#ip address 10.1.0.1 255.255.255.252
CE1(config-if)#exit
CE1(config)#interface fei-0/1/0/2
CE1(config-if)#exit
CE1(config)#ip route 10.2.0.0 255.255.0.0 10.1.0.2
PE1(config)#ip route vrf vpn_a 10.1.0.0 255.255.0.0 10.1.0.1

PE1(config)#router bgp 100
PE1(config-bgp)#address-family ipv4 vrf vpn_a
PE1(config-bgp-af)#redistribute static
PE1(config-bgp-af)#end
3.1.2.3 Configuring RIP Between a CE and a PE

To run RIP between a CE and a PE on ZXR10 M6000, perform the following steps.
1 ZXR10(config)#router rip This enters RIP configuration mode.
2 ZXR10(config)#version 2 This configures RIPv2.
3-7

3 ZXR10(config-rip)#address-family ipv4 vrf < vrf-name> This enters VRF address family
configuration mode.
ZXR10(config-rip-vrf)#no auto-summary This disables auto summary function.
ZXR10(config-rip-vrf)#version 2 This configures RIPv2.
ZXR10(config-rip-vrf)#network < network-number> < wild-card> This advertises direct-connected

network segment to RIP.
ZXR10(config-rip-vrf)#redistribute connected This redistributes direct-connected

route to RIP.
ZXR10(config-rip-vrf)#redistribute bgp-int This redistributes bgp-int to RIP.

mode.
5 ZXR10(config)#address-family ipv4 vrf < vrf- name> This enters VRF address family
configuration mode.
ZXR10(config-bgp-af)#redistribute rip This redistributes RIP route.
Example
As shown in Figure 3-2, RIP runs between CE1 and PE1.
Figure 3-2 Running RIP between CE and PE
Run RIP protocol on CE1 and PE1 respectively. Distribute routing information to each
other in rip vrf and bgp vrfon PE1.
CE1(config)#router rip
CE1(config)#no auto-summary
CE1(config-rip)#version 2
CE1(config-rip)#network 10.1.0.0 0.0.0.3
3-8

CE1(config-rip)#redistribute connected
CE1(config-rip)#exit
PE1(config)#router rip
PE1(config-rip)#version 2
PE1(config-rip)#address-family ipv4 vrf vpn_a
PE1(config-rip-vrf)#no auto-summary
PE1(config-rip-vrf)#version 2
PE1(config-rip-vrf)#network 10.1.0.0 0.0.0.3
PE1(config-rip-vrf)#redistribute bgp-int
PE1(config-rip-vrf)#exit
PE1(config-rip)#exit
PE1(config)#address-family ipv4 vrf vpn_a
PE1(config-bgp-af)#redistribute rip
PE1(config-bgp-af)#redistribute connected
PE1(config-bgp-af)#exit
3.1.2.4 Configuring OSPF Between a CE and a PE

To run OSPF between CE and PE on ZXR10 M6000, perform the following steps.
1 ZXR10(config)#router ospf < process-id> [ vrf < vrf-name> ] This enters OSPF VRF configuration
mode.
2 ZXR10(config)#network< network-number> < wild-card> area < This designates the interfaces to run
area-id> OSPF and defines area-ID to these
interfaces.
3 ZXR10(config-ospfv2)#redistribute bgp-int This redistributes bgp-int route.

mode.
5 ZXR10(config-bgp)#address-family ipv4 vrf < vrf-name> This enters VRF address family
configuration mode.
6 ZXR10(config-ospfv2-af)#redistribute { ospf-int } This redistributes ospf-int routes.
Example
As shown in Figure 3-3, OSPF runs between CE1 and PE1.
3-9

Figure 3-3 Running OSPF between CE and PE
CE1(config)#router ospf 1
CE1(config-ospfv2)#network 10.1.0.0 0.0.0.3 area 0.0.0.0
PE1(config)#router ospf 2 vrf vpn_a
PE1(config-ospfv2)#redistribute bgp-int
PE1(config-bgp-af)#redistribute ospf-int
3.1.2.5 Configuring EBGP Between a CE and a PE

To configure External Border Gateway Protocol (EBGP) between a CE and a PE on ZXR10
M6000, perform the following steps.

mode.
2 ZXR10(config)#address-family ipv4 vrf < vrf-name> This enters corresponding VRF

address family configuration mode.
3 ZXR10(config-bgp-af)#neighbor < ip-address> remote-as < This configures an EBGP neighbor

as-number> or AS number of a neighbor peers.
Example
As shown in Figure 3-4, EBGP runs between CE1 and PE1.
3-10

Figure 3-4 Running EBGP between CE and PE
Configure BGP on CE1 and PE1 respectively. Make sure that CE1 and PE1 can distribute
route to each other.
CE1(config)#router bgp 65001
CE1(config-bgp)#neighbor 10.1.0.2 remote-as 100
CE1(config-bgp)#neighbor 10.1.0.2 activate
CE1(config-bgp)#redistribute connected
CE1(config-bgp)#exit
PE1(config-bgp-af)#neighbor 10.1.0.1 remote-as 65001
PE1(config-bgp-af)#neighbor 10.1.0.1 activate
3.1.2.6 Configuring MPBGP

To configure MPBGP on ZXR10 M6000, perform the following steps.
1 ZXR10(config)#router bgp < as-number> This enters BGP configuration mode
2 ZXR10(config)#neighbor < ip-address> remote-as < as-number> This configures BGP neighbor.
3 ZXR10(config-bgp)#neighbor < ip-address> update-source This specifies update-source IP

loopback < number> address as its own loopback address
of MPBGP set link.
4 ZXR10(config-bgp)#address-family vpnv4 This enters VPNv4 address family

configuration mode.
3-11

5 ZXR10(config-bgp)#neighbor < ip-address> activate This activates vpnv4 ability of

neighbor.
Example
As shown in Figure 3-5, MPBGP runs between PE1 and PE2.
Figure 3-5 MPBGP Protocol Configuration
Caution!
Before perform the following configurations, make sure that PE1 and PE2 can ping each
other by using their loopback addresses.
PE1(config-bgp)#neighbor 1.1.1.3 remote-as 100
PE1(config-bgp)#neighbor 1.1.1.3 update-source loopback1
PE1(config-bgp)#address-family vpnv4

3-12

3.1.2.7 MPLS VPN Advanced Function Configuration
Configuring AS Override
When BGP runs between PE and CE, users want to reuse AS number in different sites. To
provide the connective between CE1 and CE2, a new method called AS override is used.
After AS override is configured on PE, but before PE sends route update packets to CE,
PE will replace the AS number of each direct-connectd CE device in the entity AS_PATH
by its own AS number. The length of AS_PATH is still kept when AS override is configured.
To configure AS override on ZXR10 M6000, perform the following steps.

mode.
2 ZXR10(config)#address-family ipv4 vrf < vrf-name> This enters IPv4 VRF address family
configuration mode.
3 ZXR10(config-bgp-af)#neighbor < neighbor-address> as-override This configures PE to replace the AS

number of each direct-connected CE
device by its own AS number in the
entity AS_PATH.
Configure Export Map and Import Map

The meanings of Export Map and Import Map are described below,
l Import Map
VRF can save its concerned route prefix by means of import map.
l Export map
The export map is used to configure different Route Targets (RTs) to route prefix.
Different VRFs can selective accept the prefixes with different RTs.
To configure export and import map, perform the following steps on ZXR10 M6000.
1 ZXR10(config)#ip vrf < vrf-name> This configures a VPN instance and

enters VPN instance configuration
mode.
2 ZXR10(config-vrf)#address-family { ipv4| ipv6} This acticates IPv4 or IPv6 address

family.
3-13

3 ZXR10(config-vrf-af)#export map < route-map-name> This configures VRF-related export

map.
The name of route map ranges from
1 to 32 characters.
ZXR10(config-vrf-af)#import map < route-map-name> This configures VRF-related import

map.
The name of route map ranges from
1 to 32 characters.
Example
As shown in Figure 3-6. P acts as a Router Reflector (RR), the loopback1 address of PE1
is 61.139.36.34/32, the loopback1 address of PE2 is 61.139.36.35/32, and the loopback1
address of P is 61.139.36.31/32.
Figure 3-6 RR Configuration Example Topology
l Configuration Requirements
à Make sure that PE1 and PE2 can learn loopback addresses between each other.
PE1 and PE2 establish LDP neighborhood with RR respectively.
à RR establishes MP-Interior Border Gateway Protocol (IBGP) neighborhood
with PE1 and PE2 respectively. PE1 and PE2 are RR clients, their Loopback
addresses are used to set up BGP connection.
à A VRF called ok is configured on PE1 and PE2. Configure the same RDs and
RTs.
RR establishes MP-IBGP neighborhood with PE1 and PE2 respectively. PE1 and PE2
are RR clients. PE1 and PE2 advertise a direct-connected route formed by loopback
interface on the private network respectively. As a result, the local PE can learn the
private network loopback route from the peer PE. The next hop of the this route is the
direct-connected address that is used to establish IGP neighborhood with the RR by
the peer PE.
l Configuration Procedure
Configuration on RR (P):
P(config)#router bgp 65190
P(config)#no bgp default route-target filter
P(config-bgp)#neighbor 61.139.36.34 remote-as 65190
P(config-bgp)#neighbor 61.139.36.34 update-source loopback1
P(config-bgp)#neighbor 61.139.36.35 remote-as 65190
3-14

P(config-bgp)#neighbor 61.139.36.35 update-source loopback1

P(config-bgp)#address-family vpnv4
P(config-bgp-af)#neighbor 61.139.36.34 active
P(config-bgp-af)#neighbor 61.139.36.35 active
P(config-bgp-af)#neighbor 61.139.36.34 route-reflector-client
P(config-bgp-af)#neighbor 61.139.36.35 route-reflector-client
PE1(config)#ip vrf ok
PE1(config-vrf)#rd 1:1
PE1(config-vrf)#address-family ipv4
PE1(config-vrf-af)#route-target 1:1
PE1(config-vrf-af)#exit
PE1(config-vrf)#exit
PE1(config-bgp-af)#neighbor 61.139.36.31 active
PE1(config-bgp)#exit
PE1(config-if)#ip vrf forwarding ok
PE1(config-if)#exit
PE1(config-bgp)#address-family ipv4 vrf ok
PE2(config)#ip vrf ok
PE2(config-vrf-af)#route-target 1:1
PE2(config-if)#ip vrf forwarding ok
3-15


PE2(config-if)#exit
PE2(config-bgp)#address-family ipv4 vrf ok
l Configuration Verification
View the route learning from PE2 on PE1,
PE1#show ip protocol routing vrf ok
Routes of vpn:
status codes: *valid, >best, s-stale
Dest NextHop Intag Outtag RtPrf Protocol
*>20.20.0.0/16 20.1.2.2 163898 34 200 bgp-int
View the route learning from PE1 on PE2,

PE2#show ip protocol routing vrf ok
Routes of vpn:
*>10.10.0.0/16 30.1.2.1 164963 163863 200 bgp-int
3.1.3 MPLS VPN Maintenance

ZXR10 M6000 provides the following commands to maintain MPLS VPN.
Command Function
ZXR10#ping vrf < vrf-name> < ip-address> This inspects network connectivity.
ZXR10#show ip vrf [ brief [ < vrf-name> ] | detail [ < vrf-name> ] | summary] This shows VRF information.
ZXR10#show ip protocol routing vrf < vrf-name> [ network < ip-address> [ This shows VRF protocol routing table.
mask < net-mask> ] ]
ZXR10#show ip route vrf < vrf-name> This shows the VRF forwarding table.
ZXR10#show bgp vpnv4 unicast summary This shows the summary information of
MPBGP neighbors.
Example
l An example of the ping vrf < vrf-name> < ip-address> command output is shown below.
ZXR10#ping vrf test1 10.1.1.2
sending 5,100-byte ICMP echos to 10.1.1.2,timeout is 2 seconds.
!!!!!
ZXR10#
l An example of the show ip vrf [ brief [ < vrf-name> ] | detail [ < vrf-name> ] | summary]
command output is shown below.
3-16

ZXR10#show ip vrf
* Being deleted
Name Default RD Protocols Interfaces
vpn_a <not set>
jixi 10:10
kk 1:1689 ipv6 gei-0/5/0/1
1234567890abcdefghij 1:1 ipv4
fenix 100:100 ipv4
mng <not set> ipv4,ipv6 mgmt_eth-0/20/0/1
ZXR10#
Name VRF name
Default RD The default route identifer
Protocol The type of address family supported by this instance, v4/v6
Interfaces The name of the interface binding to VRF
l An example of the show ip protocol routing vrf < vrf-name> [ network < ip-address> [
mask < net-mask> ] ] command output is shown below.
ZXR10#show ip protocol routing vrf test1
Routes of vpn:
*> 10.1.1.0/24 10.1.1.0 153 notag 0 connected
*> 10.1.1.1/32 10.1.1.1 152 notag 0 connected
*> 10.10.10.0/24 10.10.3.3 22 17 200 bgp_int
*> 100.1.1.0/24 10.1.1.2 20 notag 20 bgp_ext
*> 200.1.1.0/24 10.10.3.3 21 27 200 bgp_int
Dest Destination address
NextHop Next hop
Intag Ingress tag
Outtag Egress tag
RtPrf Route priority
Protocol The source of route generation
3-17

3.1.4 MPLS VPN Configuration Examples

3.1.4.1 MPLS L3 VPN Configuration Example
As shown in Figure 3-7, CE1 and CE2 belong to the same VPN. The loopback address of
CE1 is 100.1.1.1/24, and that of CE2 is 200.1.1.1/24.
Make sure that CE1 and CE2 can learn the loopback routes between each other by using
OSPF. The BGP runs between CE1 and PE1, while the OSPF runs between CE2 and PE2.
CE1 and CE2 can learn the routes from each other, and the ping is successful between
them.
Figure 3-7 MPLS L3VPN Basic Configuration Example Topology
The interface addresses are listed in Table 3-1.
Table 3-1 MPLS VPN Basic Configuration Address Table
Device Interface Name Address
CE1 gei-0/1/0/1 10.1.1.2/24
PE1 gei-0/1/0/2 10.1.1.1/24
gei-0/1/0/3 10.10.12.1/24
P gei-0/1/0/4 10.10.12.2/24
gei-0/1/0/5 10.10.23.2/24
PE2 gei-0/1/0/6 10.10.23.3/24
gei-0/1/0/7.10 10.10.10.1/24
CE2 gei-0/1/0/8.10 10.10.10.2/24
1. Configure the IP addresses of loopback1 and physical interface on CE1. Establish
EBGP neighborhood between CE1 and PE1. Advertise the loopback address in BGP.
3-18

2. Configure the IP addresses of loopback1 and gei-0/1/0/3 on PE1. Configure a VRF

called test1. Bind the interface gei-0/1/0/2 to the test 1 and configure IP address.
Configure OSPF and advertise the network segment 10.0.0.0/8 in OSPF. Establish
MPBGP neighborhood between PE1 and PE2, and enable VPNv4. Establish EBGP
neighborhood between PE1 and CE1. Enable LDP on the interface gei-0/1/0/3.
Specify the loopback1 address as the LDP router ID.
3. Configure the IP addresses of gei-0/1/0/4 and gei-0/1/0/5 on P. Configure OSPF and
advertise the network segment 10.0.0.0/8 in OSPF. Enable LDP on the interfaces
gei-0/1/0/4 and gei-0/1/0/5. Configure loopback1 and specify the loopback1 address
as the LDP router ID.
4. Configure the IP addresses of loopback1 and gei-0/1/0/6. Configure a VRF
called test1. Bind the interface gei-0/1/0/7 to the test1 and configure IP address.
Configure OSPF and advertise the network segment 10.0.0.0/8 in OSPF. Establish
MPBGP neighborhood between PE1 and PE2, and enable VPNv4. Establish OSPF
neighborhood between CE2 and PE2. Enable LDP on the interface gei-0/1/0/6.
5. Configure the IP addresses of loopback1 and gei-0/1/0/8.10. Configure OSPF and
advertise the network segments 10.10.10.2 and loopback 200.1.1.1 in OSPF.
CE1(config)#interface loopback1
CE1(config-if)#exit
CE1(config)#interface gei-0/1/1/1
CE1(config-if)#exit
CE1(config-bgp)#network 100.1.1.0 255.255.255.0
PE1(config)#ip vrf test1
PE1(config-vrf-af)#route-target import 100:1
PE1(config-vrf-af)#route-target export 100:1
PE1(config-if)#exit
PE1(config-if)#mpls ldp
3-19

PE1(config-ldp)#route-id loopback1
PE1(config-if)#ip vrf forwarding test1
PE1(config-if)#exit
PE1(config-bgp)#address-family ipv4 vrf test1
PE1(config-bgp-af)#exit-address-family
Configuration on P:
P(config)#interface gei-0/1/0/4
P(config-if)#ip address 10.10.12.2 255.255.255.0
P(config-if)#exit
P(config)#mpls ldp
P(config-ldp)#interface gei-0/1/0/4
P(config-ldp-if)#exit
P(config-ldp)#exit
P(config-if)#exit
P(config)#mpls ldp
P(config-ldp)#exit
P(config)#interface loopback1
P(config-if)#exit
P(config)#router ospf 1
P(config)#mpls ldp
P(config-ldp)#router-id loopback1
P(config-ldp)#exit
3-20

P(config-ospfv2)#network 10.0.0.0 0.255.255.255 area 0.0.0.0

P(config-ospfv2)#exit
Configuration on PE2 (here, PE2 connects to CE2 through an Ethernet sub-interface):

PE2(config-if)#exit
PE2(config-if)#exit
PE2(config)#mpls ldp
PE2(config)#interface gei-0/1/0/7.10
PE2(config-subif)#exit
PE2(config)#vlan-configuration
PE2(vlan-config)#interface gei-0/1/0/7.10
PE2(subvlan-if-config)#encapsulation-dot1q 10
PE2(subvlan-if-config)#exit
PE2(vlan-config)#exit
PE2(config-subif)#ip vrf forwarding test1
PE2(config-subif)#ip address 10.10.10.1 255.255.255.0
PE2(config)#router ospf 2 vrf test1
3-21

CE2(config-if)#exit
CE2(config)#interface gei-0/1/0/8.10
CE2(config-if)#exit
CE2(config)#vlan-configuration
CE2(vlan-config)#interface gei-0/2/0/8.10
CE2(subvlan-if-config)#encapsulation-dot1q 10
CE2(subvlan-if-config)#exit
CE2(vlan-config)#exit
CE2(config-subif)#ip address 10.10.10.2 255.255.255.0
CE2(config-ospf)#network 10.10.10.2 0.0.0.0 area 0
CE2(config-ospf)#network 200.1.1.1 0.0.0.0 area 0
View the EBGP connection running between CE1 and PE1, as shown below.
ZXR10#show ip bgp summary
Neighbor Ver As MsgRcvd MsgSend Up/Down(s) State/PfxRcd

10.1.1.1 4 100 0 12 00:00:09 0
View the routing table of CE1. Here, the BGP route is the VPN route learnt by CE1.
ZXR10#show ip forwarding route
IPv4 Routing Table:
10.1.1.0/24 10.1.1.2 gei-0/1/0/1 DIRECT 0 0
10.1.1.0/32 10.1.1.0 gei-0/1/0/1 MARTIAN 0 0
10.1.1.2/32 10.1.1.2 gei-0/1/0/1 ADDRESS 0 0
10.1.1.255/32 10.1.1.255 gei-0/1/0/1 BROADCAST 0 0
100.1.1.0/24 100.1.1.1 loopback1 DIRECT 0 0
100.1.1.0/32 100.1.1.0 loopback1 MARTIAN 0 0
100.1.1.1/32 100.1.1.1 loopback1 ADDRESS 0 0
100.1.1.255/32 100.1.1.255 loopback1 BROADCAST 0 0
200.1.1.1/32 10.1.1.1 gei-0/1/0/1 BGP 20 0
3-22

3.1.4.2 MPLS VPN OSPF SHAM-LINK Configuration Example
As shown in Figure 3-8, CE1 and CE2 belong to the same VPN. The loopback address of
CE1 is 100.1.1.1/24, and that of CE2 is 200.1.1.1/24.
Make sure that CE1 and CE2 can learn the loopback routes from each other through the
sham-link running between PE1 and PE2. CE1 and PE1 run OSPF VRF. CE2 and PE2
run OSPF VRF.
Figure 3-8 MPLS VPN OSPF SHAM-LINK Configuration Example Topology
Table 3-2 MPLS VPN OSPF SHAM-LINK Address Table
CE1 gei-0/1/0/1 10.1.1.2/24
gei-0/1/0/9 20.1.1.2/24
PE1 gei-0/1/0/2 10.1.1.1/24
gei-0/1/0/3 10.10.12.1/24
P gei-0/1/0/4 10.10.12.2/24
gei-0/1/0/5 10.10.23.2/24
PE2 gei-0/1/0/6 10.10.23.3/24
gei-0/1/0/7.10 10.10.10.1/24
CE2 gei-0/1/0/8.10 10.10.10.2/24
gei-0/1/0/10 20.1.1.1/24
1. Configure the IP addresses of loopback and physical interfaces on CE1. Configure
OSPF route.
2. Advertise the loopback interface IP address and the direct-connected network
segment in OSPF.
3-23

3. Set up SHAM-LINK.
CE1(config-if)#exit
CE1(config-if)#exit
CE1(config-if)#exit
CE1(config-ospfv2)#network 10.1.1.0 0.0.0.255 area 0
PE1(config-if)#exit
PE1(config-if)#exit
PE1(config-if)#exit
PE1(config-if)#exit
3-24

PE1(config-ospfv2)#router-id 10.10.1.1
PE1(config-ospfv2)#network 10.1.1.0 0.0.0.255 area 0
PE1(config-ospfv2)#area 0 sham-link 64.64.64.1 64.64.64.2
Configuration on P:
P(config)#mpls ldp
P(config-ldp)#exit
P(config-if)#exit
P(config)#mpls ldp
P(config-ldp)#exit
P(config)#interface loopback1
P(config-if)#exit
P(config-ospfv2)#network 10.0.0.0 0.255.255.255 area 0.0.0.0
P(config-ospfv2)#exit
P(config)#mpls ldp
3-25

P(config-ldp)#exit
Configuration on PE2 (here, PE2 connects to CE2 through an Ethernet sub-interface):

PE2(config-if)#exit
PE2(config-if)#exit
PE2(config-if)#exit
PE2(config)#vlan-configuration
PE2(vlan-config)#interface gei-0/1/0/7.10
PE2(subvlan-if-config)#encapsulation-dot1q 10
PE2(subvlan-if-config)#exit
PE2(vlan-config)#exit
PE2(config-subif)#ip address 10.10.10.1 255.255.255.0
PE2(config-ospfv2)#area 0 sham-link 64.64.64.2 64.64.64.1
3-26


CE2(config-if)#exit
CE2(config-subif)#exit
CE2(config)#vlan-configuration
CE2(vlan-config)#interface gei-0/1/0/8.10
CE2(subvlan-if-config)#encapsulation-dot1q 10
CE2(subvlan-if-config)#exit
CE2(vlan-config)#exit
CE2(config-ospfv2)#exit
3.1.4.3 Cross-Domain Option Back-to-Back (VRF-VRF) Configuration Example
As shown in Figure 3-9, custom has two sites, site 1 and 2, and they need VPN connection.
Site 1 connects to AS100, and site 2 connects to AS200. Both site 1 and site 2 provide
MPLS VPN. To set up MPLS VPN connection between site 1 and site 2, back-to-back
(VRF-VRF) is used. This is the simplest mode to realize VPN between ASs.
3-27

Figure 3-9 MPLS VPN Cross-Domain Configuration Example
1. All of PE1, PE2 and PE3, PE4 have VPN1. The RD is 1:1, and the RT is 1:1.
2. Establish LDP, IGP and MPIGP neighborhoods between PE1 and PE2. Establish LDP,
IGP and MP-IBGP neighborhoods between PE3 and PE4. Advertise the loopback
addresses by IGP.
1. Bind vpn1 to PE1. Establish EBGP connection between PE1 and CE1.
PE1(config-bgp)#address-family ipv4 vrf vpn1
2. Establish MP-IBGP neighborhood between PE1 and PE2 by using the loopback
interfaces 1.2.3.4 and 2.3.4.5.
Configuration of PE1 is the same to PE2.

3. Bind vpn1 to PE4. Establish EBGP connection between PE4 and PE2.
IPv4 and VPNv4 are enabled among PEs.

4. Establish MP-IBGP neighborhood between PE3 and PE4 by using the loopback1
interfaces 3.4.5.6 and 4.5.6.7.
3-28


Configuration of PE4 is the same to PE3.

5. PE2 specifies PE3 as its MPEBGP neighbor in BGP VPNv4 address family mode. IP
address of INTB is 150.3.2.3.
6. Bind vpn1 to PE3.
PE3(config)#interface INTB
PE3(config-if)#ip vrf forwarding vpn1
7. Bind vpn1 to PE2.
PE2(config)#interface INTA
PE2(config-if)#ip vrf forwarding vpn1
8. PE3 specifies PE2 as its MPEBGP neighbor in VPNv4 address family mode. IP
address of INTA is 150.3.2.2.
9. PE1 redistributes direct-connected route in VPNv4 address family mode.
PE1(config-bgp)#redistribute connected
10. PE4 advertises the network segment 200.1.1.0 in VPNv4 address family mode.
PE4(config-bgp-af)#network 200.1.1.0 255.255.255.0
11. Enable LDP between PE1 and PE2 to establish LSP. The interface gei-0/1/0/1 is used
to interconnected PE2 by PE1.
Enable LDP between PE3 and PE4 to establish LSP.
Use the show ip bgp summary command on PE1 to view the EBGP neighborhood
established with 100.1.1.2.
PE1#show ip bgp summary

100.1.1.2 4 65000 0 0 00:10:00
3-29

Use the show bgp vpnv4 unicast neighbor 1.2.3.4 command on PE2 to view the
configuration, as shown below
PE2# show bgp vpnv4 unicast neighbor 1.2.3.4
Neighbor capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast: advertised and received
Address family VPNv4 Unicast: advertised and received
Graceful Restart Capability: advertised and received
Use the show ip bgp summary command on PE4 to view the EBGP neighborhood
establishing with 200.1.1.2.
200.1.1.2 4 65000 0 0 00:15:00
Use the show bgp vpnv4 unicast neighbor 4.5.6.7 command on PE3, as shown below.
PE2# show bgp vpnv4 unicast neighbor 4.5.6.7

Neighbor capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast: advertised and received
Address family VPNv4 Unicast: advertised and received
Graceful Restart Capability: advertised and received
Use the show ip bgp summary command on PE2 to view the MP-EBGP neighborhood
established with 150.3.2.3 (PE3).
150.3.2.3 4 200 0 0 00:22:35
3.1.5 MPLS VPN Fault Handling

Take the topology shown in Figure 3-10 as an example to describe how to handling an
MPLS VPN fault.
3-30

Figure 3-10 Network Topology of an MPLS VPN Fault

The MPLS/VPN packets forwarding is based on an LSP, and the LSP depends on route.
Therefore, the thought to locate a fault is checking the routes, labels, private network and
public network in order.
1. Check the route on the private network. Check whether there are VRF routes learnt
from the peer PE in the VRF routing tables of the PE routers at both ends, as shown
below.
PE2#show ip protocol routing vrf fenix
vpn route limit warning!
Routes of vpn:
*> 2.2.2.0/24 100.10.1.1 212995 212999 200 bgp-int
......
PE2#
In the information displayed, check whether there is a VRF route that is advertised
by the peer PE in the Dest column (in this example, it is the route to the 2.2.2.0/24
segment), whether the NextHop is correct (the peer MPBGP neighbor address, in this
example, it is 100.10.1.1), whether there are Intag and Outtag, whether the tags are
correct, and whether the corresponding RtPrf and Protocol are correct.
2. Use the show bgp vpnv4 unicast summary comamnd to view BGP neighborhood.
PE2#show bgp vpnv4 unicast summary
Neighbor Ver As MsgRcvd MsgSend Up/Down State/PfxRcd
9.4.7.1 4 1 0 0 00:00:00 Connect
100.10.1.1 4 1 5189 5185 1d19h 6
PE2#
In this example, the State/PfxRcd of the 9.4.7.1 neighbor is Connet. This means that
it is in TCP connection stage and the MPBGP neighborhood has not be established
successfully yet. The state of the 100.10.1.1 neighbor is 6. This means that the router
learns 6 routes from the peer PE.
3-31

Here, if the value shown in State/PfxRcd is a number, the BGP neighborhood is

established. The number refers to the number of public network routes transmitted
from the BGP neighbor. If it is not a number, the BGP neighborhood is not established.
View the corresponding fields to know the current state of BGP.
3. Check the public network routes. If the public network device does not learn the route
to the MPBGP neighbor, the MPBGP neighborhood cannot be established. If there is
no 32–bit accurate route to the MPBGP neighbor on the public network, LDP cannot
distribute labels for the neighbor address. Therefore, usually it is recommended to use
the loopback address with 32–bit mask to establish MPBGP neighborhood.
If there is no route to the MPBGP neighbor, use the show running-config ospf/isis/rip
/static command to check the public network IGP configurations on the local PE and
the peer PE. Check whether the accurate route to the MPBGP neighbor is advertised
through IGP on the PE.
Use the show ip forwarding route command to view the public network routes on the
devices along the LSP on the public network. Check whether each device has an
accurate route to the MPBGP neoghbor of the peer PE.
PE2#show ip for route
IPv4 Routing Table:
*> 10.4.7.2/32 10.4.7.2 loopback64 address 0 0
*> 100.10.1.1/32 100.2.1.1 gei-0/0/0/8 ospf 110 1
*> 100.10.2.2/32 100.10.2.2 loopback1 address 0 0
......
PE2#
The “*> 100.10.1.1/32 100.2.1.1gei-0/0/0/8 ospf 110 1” route is the route to the MPBGP
neighbor learnt through IGP.
Meanwhile, the “*> 100.10.2.2/32 100.10.2.2 loopback1 address 0 0” route is needed
to be redistributed in MPBGP and learnt by the peer PE.
4. Use the show mpls forwarding table command to check whether public network
labels are distributed for the 32–bit address of the MPBGP neighbor. If no label is
distributed, use the show mpls ldp neighbor instance command to check whether LDP
neighborhood is established. If the neighborhood is normal and there is no label,
check whether label filter is used in LDP. An example of the show mpls forwarding
table command output is shown below.
PE2#show mpls forwarding-table
Local Outgoing Prefix or Outgoing Next Hop M/S
16384 Untagged 100.10.1.1/32 gei-0/0/0/8 100.2.1.1 M
PE2#
The information shows that public network labels are distributed for the 32–bit address
of the MPBGP neighbor. The outgoing label is distributed by the peer, because
3-32

100.10.1.1 is the loopback address of the peer. As the last hop of the LSP, the peer
distributes the Untagged label for the neighbor. The label distributed by the local
device is 16384. This label is used by the upstream LSR.

The flow to handle an MPLS VPN fault is shown in Figure 3-11.
3-33

Figure 3-11 Flow to Handle an MPLS VPN Fault
3-34


The procedure to handle an MPLS VPN fault is described below.
1. View private network label.
Use the show ip protocol routing vrf command to view whether the private out label of
the local PE router is allocated by the peer PE.
ZXR10#show ip protocol routing vrf ok
Routes of vpn:
Dest NextHop Intag Outtag RtPrf Protoc

*> 33.33.33.39/32 10.1.2.2 163845 163544 200 bgp-int
Inspect whether the value of Outtag (163544) is the same to the Intag value of the
peer PE. If it is, the private label is correct. Otherwise, the private label is incorrect.
2. Inspect MPBGP neighborhood.

show bgp vpnv4 unicast summary

10.1.1.1 4 100 3 12 00:00:09
3. Use the show running-config bgp command to view MPBGP configuration. For each
VRF, inspect whether the IGP routes are redistributed to VRF BGP. For ordinary
neighbors, inspect whether the neighbor is enabled in VPNv4 address family. Make
sure that VPNv4 route can be transmitted by MBGP neighbor.
ZXR10#show running-config bgp
!
router bgp 200
neighbor 33.33.33.39 remote-as 200
neighbor 33.33.33.39 activate
neighbor 33.33.33.39 update-source loopback33
$
address-family ipv4 vrf ok
redistribute connected
$
address-family vpnv4
$
!
Inspect whether the neighbor configuration is correct. Inspect whether the value
behind remote-as is correct. Inspect whether the direct-connected route is
redistributed in VRF address family configuration mode. Inspect whether activate the
neighbor in VPNv4 address family configuration mode.
4. Check whether there are routes to the LDP router IDs of all devices along the
LSP in the public network routes, and whether there are routes to the connection
3-35

establishment address of the MPBGP neighbor. Use the show ip forwarding route
command command to inspect public network route.
ZXR10#show ip forwarding route
IPv4 Routing Table:
1.1.1.38/32 170.1.1.38 gei-0/3/0/10 OSPF 110 2
5. Use the show running-config bgp command to view BGP configuration.
!
!
router bgp 200
neighbor 200.1.1.35 update-source loopback40
address-family ipv4 vrf ok

$
$
!
6. Use the show running-config ospf/isis/rip/static command to view public network IGP
configuration.
7. Use the show mpls forwarding table command to view whether every device in the
entity LSP path already allocates public network labels to the 32–bit address (32–bit
loopback address recommended) of MPBGP neighbor of the two PEs correctly.
Inspect whether the ingress label of every device is the egress label of its next-hop.
ZXR10#show mpls forwarding-table
Local Outgoing Prefix or Outgoing Next Hop

4115 0 33.33.33.39/32 gei-0/2/1/2 10.1.2.2
8. Use the show mpls ldp neighbor command to view LDP neighbor. Inspect whether LDP
neighborhood is established correctly between the adjacent PE and P.
ZXR10(config)#show mpls ldp neighbor 10.10.10.2 detail
Peer LDP Ident: 10.10.10.2:0; Local LDP Ident 10.10.10.1:0
TCP connection: 10.10.10.2.1024 - 10.10.10.1.646
state: Oper; Msgs sent/rcvd: 10/12; Downstream
Up Time: 00:06:48
LDP discovery sources:
fei-0/1/0/3; Src IP addr: 10.10.10.2
holdtime: 15000 ms, hello interval: 5000 ms
Addresses bound to peer LDP Ident:
10.10.10.2 1.1.1.1
3-36

Session holdtime: 180000 ms; KA interval: 60000 ms
Here, the content of State: Oper shows that LDP is established correctly.
9. Use the show running--config ldp command to view MPLS configuration. Inspect
whether mpls ldp router-id is configured correctly. Inspect whether LDP is enabled
on related interfaces.
ZXR10#show running-config ldp
! <MPLS>
mpls ldp instance 1
router-id loopback1
interface gei-0/3/0/10
$
! /<MPLS>
3.2 MPLS VPN Route Aggregation Configuration

3.2.1 MPLS VPN Route Aggregation Overview
By means of the aggregation-address command in BGP vrf address family mode, BGP
protocol can aggregate the learnt VPN routes to a route for advertising. In this way, the
route entries in VPN routing table can be reduced observably.
3.2.2 Configuring MPLS VPN Route Aggregation

To configure MPLS VPN route aggregation on ZXR10 M6000, perform the following steps.

mode.
2 ZXR10(config-bgp)#address-family ipv4 vrf < vpn-name> This enters IPv4 VRF address family
configuration mode.
3 ZXR10(config-bgp-af)#aggregate-address < ip-address> < net-mask> This creates an aggregation policy in

[ as-set] [ summary-only] strict] [ attribute-map < route-map name> ] [ VRF routing table.
suppress-map < route-map name> ]
< ip-address> The aggregation network to be created, in dotted decimal notation
< net-mask> The aggregation mask to be created, in dotted decimal notation
as-set Generate the information of AS set path
3-37

summary-only Filter all more special routes from the update
strict According to RFC1771, the routes which MED and NEXT_HOP attributes
are the same can be aggregated only. MED and NEXT_HOP attributes will
not be used if the command is used without the strict keyword.
attribute-map Attribute map
< route-map name> Name of attribute-map, the length is 1-32 characters.
suppress-map Suppress map
< route-map name> The name of suppress map, the length is 1-32 characters.
3.2.3 MPLS VPN Route Aggregation Maintenance

ZXR10 M6000 provides the following command to maintain MPLS VPN route aggregation.
Command Function
ZXR10#show ip route vpn This shows the route information of

VPN instance.
An example of the show ip route vpn command output is shown below. Here, the
informations about route aggregation can be viewed.
ZXR10#show ip route vpn
Routes of vpn:
Dest NextHop Type ASN Addr Peer

1.1.1.0/24 1.1.1.1 0 1 1 0.0.0.0
1.1.1.1/32 1.1.1.1 0 1 1 0.0.0.0
Dest Route prefex and mask
NextHop Route next hop
Type RD type
ASN The administrator value of RD
Addr The assigned value of RD
Peer Neighbor IP address
3-38

3.2.4 MPLS VPN Route Aggregation Configuration Example

As shown in Figure 3-12, CE1 belongs to AS200, both PE1 and PE2 belong to AS100, and
CE2 belongs to AS300. PE1 and PE2 establish MPBGP neighborhood by using loopback
addresses. CE1 and PE1 establish EBGP neighborhood, and CE1 and PE1 establish
EBGP neighborhood.
Both CE1 and CE2 belong to the same VPN, which advertise route 150.1.0.0/16 and
150.2.0.0/16 to PE1 respectively. PE1 aggregates two routes to 150.0.0.0/8, and then
advertises it to PE2. After that, PE2 only learns the aggregated route 150.0.0.0/8.
CE1 gei-0/1/0/1 20.0.0.2/24
PE1 gei-0/1/0/2 20.1.0.1/24
gei-0/1/0/4 30.0.0.1/24
gei-0/1/0/5 10.0.0.1/24
PE2 gei-0/1/0/6 10.0.0.2/24
CE2 gei-0/1/0/3 30.0.0.2/24
Figure 3-12 MPLS VPN Route Aggregation Configuration Example Topology
Table 3-3 MPLS VPN Interface Address Table
CE1 gei-0/1/0/1 10.1.1.2/24
PE1 gei-0/1/0/2 10.1.1.1/24
gei-0/1/0/3 10.10.12.1/24
P gei-0/1/0/4 10.10.12.2/24
gei-0/1/0/5 10.10.23.2/24
3-39

PE2 gei-0/1/0/6 10.10.23.3/24
gei-0/1/0/7 10.10.10.1/24
CE2 gei-0/1/0/8 10.10.10.2/24
1. Establish MP-BGP neighborhood between PE1 and PE2. The loopback address of
PE1 is 1.1.1.1/32, and that of PE2 is 1.1.1.2/32.
2. Configure the same vpn1 on PE1 and PE2. Bind gei-0/1/0/2 and gei-0/1/0/4 to VPN1.
3. Establish EBGP neighborhood between CE2 and PE1, CE1 and PE1 respectively.
CE1(config-if)#exit
CE2(config-if)#exit

PE1(config-if)#exit
PE1(config-if)#exit
3-40

PE1(config-if)#exit
PE1(config-if)#exit
PE1(config-bgp)#aggregate-address 150.0.0.0 255.0.0.0 summary-only
PE2(config-if)#exit
PE2(config-if)#exit
3-41

View VRF routing table on PE1. Here, both the sub-routes and the aggregated route can
be viewed.
PE1(config)#show ip protocol routing vrf test1
Routes of vpn:
*> 150.0.0.0/8 0.0.0.0 87 notag 254 bgp-aggr-discard
*> 150.1.0.0/16 20.0.0.2 86 notag 20 bgp-ext
*> 150.2.0.0/16 30.0.0.2 85 notag 20 bgp-ext
View PE2 routing table. Here, only the aggregated route can be viewed.
PE2(config)#show ip protocol routing vrf test1
Routes of vpn:
*> 150.0.0.0/8 1.1.1.1 165366 87 200 bgp-int
3.2.5 MPLS VPN Route Aggregation Fault Handling

Take the topology shown in Figure 3-13 as an example to describe how to handle an MPLS
VPN route aggregation fault.
3-42

Figure 3-13 Network Topology of an MPLS VPN Route Aggregation Fault

If routes are not aggregated or the peer PE does not learn the aggregation route, check
whether the PE on which aggregation is configured can generate an aggregation route first,
and then check the PE that needs to learn the aggregation route can learn the aggregation
route. The detailed procedure is described below.
1. Check whether the aggregation configuration is correct.
2. Check whether the PE can generate an aggregation route.
a. Check whether there are sub-routes of the aggregation route. If there is no
sub-route, the aggregation route cannot be generated.
b. Check whether the subnet routes are redistributed in the BGP IPv4 VRF address
family. Only after the subnet routes are redistributed to BGP is it possible to
generate an MPBGP aggregation route.
c. Check whether there is any policy that makes the PE fails to generate an
aggregation route. Check whether limit of the number of routes is configured.
3. Check whether the aggregation route can be advertised to the peer. Check whether
there is any policy that may affect the advertisement of the aggregation route.
4. Check whether the peer can learn the aggregation route. Check whether there is any
policy that may affect the learning of the aggregation route. Check whether limit of the
number of routes is configured.
5. If the fault persists after the checks above, it is necessary to check whether the MPLS
VPN basic configurations are correct.

The flow to handle an MPLS VPN route aggregation fault is shown in Figure 3-14.
3-43

Figure 3-14 Flow to Handle an MPLS VPN Route Aggregation Fault

The procedure to handle an MPLS VPN route aggregation fault is described below.
1. Use the show running-config bgp command to check the BGP configuration, as shown
below.
! <BGP>
router bgp 1
address-family ipv4 vrf test

aggregate-address 159.1.0.0 255.255.0.0 summary-only
aggregate-address 147.0.0.0 255.0.0.0 summary-only
3-44

redistribute static
$
$
! /<BGP>
ZXR10#
In the VRF named test, there are two aggregation routes, “aggregate-address
159.1.0.0 255.255.0.0 summary-only” and “aggregate-address 147.0.0.0 255.0.0.0
summary-only”.
2. Check whether there is an aggregation route and the sub-routes on the PE on which
route aggregation is configured. If there is no sub-routes to be aggregated, the
aggregation route will not be generated.
ZXR10(config)#show ip protocol routing vrf test
vpn route limit warning!
Routes of vpn:
*> 100.10.4.0/24 100.10.4.1 212996 notag 0 direct
*> 100.10.4.1/32 100.10.4.1 212995 notag 0 address
*> 147.0.0.0/8 0.0.0.0 212998 notag 254 bgp-aggr-discard
*> 147.1.1.1/32 100.10.4.2 212997 notag 1 static
The 147.1.1.1/32 route is a local static route. According to the aggregation

configuration command “aggregate-address 147.0.0.0 255.0.0.0 summary-only” in
Step 1, the aggregation route “147.0.0.0/8” is aggregated on the device. For the
command “aggregate-address 159.1.0.0 255.255.0.0 summary-only”, there is no
related subnet routes, so the aggregation route is not generated. This is correct. An
aggregation will be generated only when there is subnet routes. When the PE learns
subnet routes, an aggregation route will be generated.
3. Check why there is no subnet routes of 159.1.0.0/16 on the PE. If there are dynamic
VRF routes between the PEs and CEs, check whether the routes in this network
segment are advertised to the PEs by the CEs. If there are static VRF routes between
the PEs and CEs, check whether static routes to this network segment is configured
on the PEs.
4. If there are subnet routes of the 159.1.0.0/16 network segments in Step 2 but the
aggregation route is not generated, use the show running-config bgp command ti check
whether the subnet routes are redistributed in BGP VRF address family. Only when
the sunnet routes are redistributed in BGP VRF will be MPBGP aggregation route be
generated.
5. Check whether a route export policy (export map) is configured in IP VRF address
family on the PE on which route aggregation is configured. If the policy is configured,
make sure that the aggregation route is allowed to be exported by this policy.
3-45

Check whether a route import policy (import map) is configured in IP VRF address
family on the PE that needs to learn the aggregation route. If the policy is configured,
make sure that the aggregation route is allowed to be imported by the policy.
6. Use the show ip vrf detail < vrf name> command and the show ip protocol routing vr
f-summary < vrf name> command to check whether the limit of the number of VPN
routes is configured on the PE advertising the aggregation route and the PE learning
the aggregation route. Check whether the number of the VPN routes reaches the limit.
7. Use the show running-config bgp command and the show running-config route-map
command to check whether an enhanced route filter is configured in MPBGP. Check
whether the filter for exporting routes is configured on the device advertising the
aggregation route. Check whether filter for importing routes is configured on the
device needing to learn the aggregation route.
If the fault cannot be solved according to the steps above, please check whether the MPLS
VPN basic configuration is correct. If the basic configuration is also correct, please ask for
technical support.
3.3 VPN Route Restriction and Alarm

3.3.1 VPN Route Restriction and Alarm Overview
In MPLS VPN network, a PE receives excessive routes from CE and other PEs, so PE
memory is exhausted and the router collapses. Therefore, it is necessary to control the
VRF routes which enter PE router from CE and PE neighbor. This function is called as
VPN Route Limit.
There are three methods to send routes from CE to PE, as shown below.
l Direct connection
l Static
l Dynamic unicast route protocol
The function of VPN Route Limit controls the routes to access to PE from CE through many
methods.
3.3.2 Configuring VPN Route Restriction and Alarm

To configure VPN route limit and alarm on ZXR10 M6000, perform the following steps.
1 ZXR10(config)#ip vrf < vrfi-name> This enters into VRF configuration

mode.
2 ZXR10(config-vrf)#address-family { ipv4| ipv6} This activates IPv4 or IPv6 address

family.
3-46

3 ZXR10(config-vrf)#maximum routes < number> { < thresholdvalue> This controls the number of routes
| warning-only} to enter into VRF and gives the
corresponding alarm.
< number> The sum of valid routes. The range is 1–42949672955.
< thresholdvalue> Route alarm threshold, it is a percentage value. The range is 1–100.
warning-only When the total number of VRF routes exceeds the threshold value, give
an alarm but not restrict the routes.
3.3.3 VPN Route Restriction and Alarm Maintenance

ZXR10 M6000 provides the following command to maintain VPN route restriction and
alarm.
Command Function
ZXR10#show ip vrf detail This shows VRF configuration is detail.
An example of the show ip vrf detail command output is shown below. By showing VRF
configuration in detail, the information of route restriction and alarm can be viewed.
PE1(config)#show ip vrf detail zte
VRF zte (VRF Id = 1); default RD 1:1
VRF label allocation mode: per-prefix
Ttl-mode:<not set>
Ds-mode: <not set>
Interfaces:
fei-0/1/0/1.1
fei-0/1/0/5
Address family ipv4:
No Export VPN route-target communities
No Import VPN route-target communities
No import route-map
No export route-map
Route warning limit 100, current count 50
No import route-map
3-47

No export route-map
Export VPN route-target communities The exported VPN route contains RT attribute.
Import VPN route-target communities The imported VPN route needs to contain RT attribute.
Route warning limit 10000 , current VPN route alarm threshold value is 10000, and there are 11 route entries.
count 11
The following example shows the configuration of limit and alarm threshold.
VRF fenix (VRF Id = 1); default RD 100:100
Description: this vrf is create for test
Ttl-mode: not set
Ds-mode: not set
Interfaces:
fei-0/0/1/1
Export VPN route-target communities
100:100
Import VPN route-target communities
100:100
No import route-map
No export route-map
Route limit 5 , warning limit 80% (4)
Address family ipv6 not active.
VRF mng (VRF Id = 8193); default RD <not set>
Ttl-mode: <not set>
Ds-mode: <not set>
Interfaces:
mgmt_eth-0/11/0/1
No import route-map
No export route-map
No import route-map
No export route-map
3-48

Export VPN route-target communities The exported VPN route contains RT attribute.
Import VPN route-target communities The imported VPN route needs to contain RT attribute.
Route limit 300 , warning limit 50% VPN limit of the number of routes is 300. When there is 150 routes (50%),
(150) the system sends alarms.
3.3.4 VPN Route Alarm Configuration Example

As shown in Figure 3-15, a L3VPN network is constructed. VRF named zte is configured
on PE1, and its both of its RT and RD is 1:1. The interface int 1 is bound to VRF zte.
The IP address of int 1 is 10.1.1.1/24, and that of port 1 is 10.1.1.2/24. CE1 accesses to
PE1 through EBGP.
Figure 3-15 VPN Route Alarm Configuration Example
1. To establish EBGP neighborhood between PE1 and CE1, configure PE1 as follows,
PE1(config-bgp)#address-family ipv4 vrf zte
Perform the corresponding configuration on CE1 to make it establish EBGP

neighborhood between PE1.
Use the show ip bgp summary command on PE1 to view whether the neighborhood
between PE1 and CE1 is established.
2. Configure the maximum value of VRF zte routes is 100 on PE1, and the route alarm
threshold value is 60%.
PE1(config)#ip vrf zte
PE1(config-vrf)#maximum routes 100 60
Use show ip vrf detail zte to view the configuration result of maximum routes.
Enable alarm and terminal monitor functions on PE1 to view the alarm if the number
of routes exceeds the threshold.
3-49

PE1#terminal monitor
PE1#configure terminal
PE1#(config)#logging on
3. CE1 advertises 50 EBGP route entries to PE1 (it does not exceed the 60% of alarm
threshold value). Use the show ip protocol routing vrf zte command to view the 50 VRF
EBGP route entries on PE1. PE1 does not give any alarm.
4. CE1 continues to advertise 20 EBGP route entries to PE1. There are 70 EBGP route
entries now (It exceeds 60% of alarm threshold value). Use the show ip protocol rout
ing vrf-summary zte command on PE1 to view the 70 VRF EBGP route entries. PE1
gives an alarm.
PE1(config)#show ip protocol routing vrf-summary zz
The total route of this vpn is 70
The corresponding alarm is displayed by PE1.

An alarm 200311 level 4 occurred at 00:00:00 01-01-2000
sent by MPU-0/20/0
%COURIER% Routes warning limit is exceeded! warning data:
The routes warning limit of zte is exceeded
5. CE1 continues to advertise 30 route entries to PE1. There are 100 EBGP route entries
(It exceeds 100 of alarm threshold value). Use the show ip protocol routing vrf-summ
ary zte command on PE1 to view the 100 VRF EBGP route entries.
PE1(config)#show ip protocol routing vrf-summary zz
The alarm that the number of VRF routes exceeds the threshold value is displayed by
PE1.
sent by MPU-0/20/0
%COURIER% Routes limit is exceeded! err data:
The routes limit of zte is exceeded
6. CE1 cancels the route entries that it advertised to PE1 before, and it advertises another
50 EBGP route entries to PE1. Use the show ip protocol routing vrf-summary zte
command on PE1 to view the 50 VRF EBGP routes. PE1 does not give any alarm.
7. Modify the route alarm threshold of VRF zte to 40% on PE1. The upper limitation of
route is still 100 entries.
PE1(config-vrf-af)#maximum routes 100 40
Use the show ip vrf detail zte command to view the configuration result of the maximum
routes command. It shows that there are 50 route entries and PE1 does not give any
alarm.
8. CE1 cancels the 50 EBGP route entries that it advertised to PE1 before, and it
advertises to PE1 again. PE1 gives an alarm to prompt that the route alarm threshold
is exceeded.
3-50

sent by MPU-0/20/0
%COURIER% Routes warning limit is exceeded! warning data:
The routes warning limit of zte is exceeded
9. Configure warning-only function of VPN route restriction alarm on vrf zte on PE1.
PE1(config-vrf-af)#maximum routes 100 warning-only
10. View the current route number, route restriction value and alarm threshold value of vrf
zte on PE1. The route number is 50, the route threshold value is not exceeded. There
is no alarm appears.
Ttl-mode:<not set>
Ds-mode: <not set>
Interfaces:
fei-0/1/0/1.1
fei-0/1/0/5
No import route-map
No export route-map
No import route-map
No export route-map
11. Advertise 60 routes from CE1. The route number exceeds the threshold value. PE1
displays the corresponding alarm. VRF zte of PE1 does not restrict the routes if the
number of routes exceeds 100.
sent by MPU-0/20/0
%COURIER% Routes limit is exceeded!
err data:The routes limit of zte is exceeded

Ttl-mode: <not set>
Ds-mode: <not set>
Interfaces:
3-51

fei-0/1/0/1.1
fei-0/1/0/5
No import route-map
No export route-map
No import route-map
No export route-map
3.3.5 VPN Route Restriction and Alarm Fault Handling

Take the topology shown in Figure 3-16 as an example to describe how to handle an MPLS
VPN route aggregation fault.
Figure 3-16 Network Topology of an MPLS VPN Route Aggregation Fault

Symptom:
The number of routes exceeds the route threshold value, and the number of routes exceeds
route alarm threshold value but no alarm appears.
Fault analysis:
l Use the show ip protocol routing vrf-summary command view the number of VPN
routes.
l Use the show bgp vpnv4 unicast summary command to view BGP neighborhood.
l Use the show ip vrf detail command to view the configuration of VPN route restriction.
l Use the show running-config alarm command to view alarm level.
3-52


The flow to handle a VPN route restriction and alarm fault is shown in Figure 3-17.
Figure 3-17 Flow to Handle a VPN Route Restriction and Alarm Fault
3-53


Use the show ip protocol routing vrf-summary command to view the number of VPN routes.
ZXR10#show ip protocol routing vrf-summary hihi
If the number of VPN routes is not in the defined range, VPN route restriction function does
not take effect.
The procedure to handle a VPN route restriction fault is described below.
1. Use the show bgp vpnv4 unicast summary command to view BGP neighborhood.
ZXR10#show ip bgp summary
15.1.1.8 4 500 31 43 00:14:55 20
Inspect whether the content shown in State/PfxRcd is a number. The number means
that the BGP neighborhood is established already. Here, the number is 20, that is to
say, 20 route entries are transmitted to neighbor.
2. Use the show ip vrf detail command to view VPN route restriction configuration. Inspect
whether the correct restriction number is configured.
ZXR10(config)#show ip vrf detail ok
VPN ok; default RD 512:512
No interfaces
Connected addresses are not in global routing table
Export VPN route-target communities
0.0.0.0:0
Import VPN route-target communities
0.0.0.0:0
No import route-map
No export route-map
Route limit 1000 , warning limit 60% (600) ,
current count 200
The route restriction threshold value is 1000 and the route alarm threshold is 60%.
There are 200 VRF routes.
3. Check the configuration of VPN route restriction and alarm and check whether the
warning-only keyword is configured. If the keyword is configured, delete it. The warn
ing-only keyword means that when the number of routes in a VRF exceeds the limit,
the system only sends alarm information but does not restricts the routes.
4. Use the show running-config alarm command to check the alarm levels. The alarm
level of an error is 4, and the alarm level of a warning is 5. If the alarm level is 4–8,
the alarm will be printed. Alarms will not be generated for the route restriction when
the alarm level is higher than 4.
3-54

3.4 L3 VPN FRR Configuration

3.4.1 L3 VPN FRR Overview
At present, the data products work as the basic communication devices of operators. The
requirements for device forwarding stability and fast fault recovery are becoming higher
and higher. Especially when there are more and more VPN communication demands
of users, the VPN FRR function is becoming more and more important. The VPN FRR
function can only be private network VPN FRR. The FRR function accomplished by the
outer labels on the public networks is not included. Therefore, L3 VPN FRR refers to the
FRR for VPN routes on private networks.
At present, for the routes that are learnt from different remote PE devices, FRR relationship
can be formed.
As shown in Figure 3-18, PE1 learns the private network routes to the same network
segment from two different next hops (PE2 and PE3). L3 VPN FRR relationship can be
formed on PE1. When CE1 sends traffic to CE2, active and standby private network routes
will be formed on PE1, thus forming L3 VPN FRR. In this way, fast traffic changeover is
accomplished.
Figure 3-18 L3 VPN FRR Network Structure
3.4.2 L3 VPN FRR Principle

The working procedure of VPN FRR is similar with that of IP FRR, as described below.
1. Detect a fault quickly. The technologies usually used include BFD and physical signal
detection.
2. Modify the forwarding plane and change the traffic over to the standby path that has
been calculated out.
3. perform route re-convergence.
4. After route re-convergence, change the traffic over to the optimal path.
3-55

3.4.3 Configuring L3 VPN FRR

To configure L3 VPN FRR, enter BGP private network configuration mode and enable the
FRR function.
Command Function
ZXR10(config-router-af)#bgp frr This enables the BGP FRR function.
3.4.4 L3 VPN FRR Maintenance

ZXR10 M6000 provides the following commands to maintain L3 VPN FRR.
Command Function
ZXR10#show ip forwarding backup route vrf This shows the standby private network
route.
3.4.5 L3 VPN FRR Configuration Example

As shown in Figure 3-19, on an L3 VPN, CE1 is directly connected to VRF 1 on PE1. CE2
establishes OSPF neighbor relationship with the VRF access interfaces on PE2 and PE3.
CE2 and R1 establish OSPF neighbor relationship. Redistribute OSPF in VRF address
family configuration on PE2 and PE3. On PE1, there are VRF 1 routes that are learnt from
PE2 and PE3. PE1 establish LDP/MP-BGP neighbor relationship with PE2 and PE3.
Figure 3-19 L3 VPN FRR Configuration Example
1. According to the network topology, construct an MP-BGP network for PE1, PE2 and
PE3.
3-56

2. Establish OSPF neighbor relationship with the VRF access interfaces of PE2 and PE3
on CE2. Establish OSPF neighbor relationship between CE2 and R1.
3. Redistribute OSPF in VRF address family configuration mode on PE2 and PE3.
4. Configure IBGP FRR in the VRF instance on PE1.
PE1(config-if)#exit
PE1(config)#interface xgei-0/2/0/3
PE1(config-if)#exit
PE1(config-if)#exit
PE1(config-ospfv2)#network 172.20.96.2 0.0.0.0area 0.0.0.0
PE1(config-ldp)#interface xgei-0/2/0/3
PE1(config-vrf)#route-target both 1:50
PE1(config-bgp-af)#bgp frr
3-57

PE1(config-if)#ip vrf forwarding zte

PE2(config-if)#exit
PE2(config-if)#exit
PE2(config-if)#ip vrf for zte
PE2(config-if)#exit
PE2(config)#router ospf 100 vrf zte
3-58


PE3(config-if)#exit
PE3(config-if)#exit
PE3(config-if)#ip vrf for zte
PE3(config-if)#exit

CE2(config-if)#exit
CE2(config-ospfv2)#exit
3-59

Verify the configuration on PE1.
PE1#show ip protocol routing vrf liuhui network 192.1.1.0 mask 255.255.255.0
Routes of vpn:
*> 192.1.1.0/24 172.20.108.2 213015 213400 200 bgp-int
*> 192.1.1.0/24 172.20.96.1 213015 213008 200 bgp-int
ZXR10(config)#sho ip forwarding route vrf liuhui 192.1.1.0
IPv4 Routing Table:
192.1.1.0/24 172.20.108.2 xgei-0/2/0/2 bgp 200 3
ZXR10 (config)#sho ip forwarding backup route vrf liuhui 192.1.1.0
IPv4 Routing Table:
192.1.1.0/24 172.20.96.1 xgei-0/2/0/3 bgp 200 3
ZXR10(config)#sho bgp vpnv4 unicast detail 1:50 192.1.1.0 255.255.255.0
BGP routing table entry for 1:50:192.1.1.0/24
1d7h received from 172.20.108.2 (5.5.5.63)
origin ?,nexthop 172.20.108.2,metric 3,localpref 100,
as path
as4 path
extended Community:RT:1:50 ,OSPF domain id :0x0005:000000640200 ,
OSPF router id :100.1.1.63,OSPF route type :0:2:0
received label 213400
1d7h received from 172.20.96.1 (172.20.96.1)
origin ?,nexthop 172.20.96.1,metric 3,localpref 100,
as path
as4 path
extended Community:RT:1:50 ,OSPF domain id :0x0005:000000640200 ,
OSPF router id :172.20.130.21,OSPF route type :0:2:0
received label 213008
According to the information, VPN FRR relationship is formed on PE1. When the active
link between PE1 and PE2 is down, VPN FRR on PE1 will change the traffic over to the
standby link from the active link, thus accomplishing fast changeover.
3.4.6 L3 VPN FRR Fault Handling

Take the topology shown in Figure 3-20 as an example to describe how to handle an L3
VPN FRR fault.
3-60

Figure 3-20 Network Topology of an L3 VPN FRR Fault

If the private network standby route cannot be formed on PE1, it is necessary to check the
following items.
1. Enter BGP private network configuration mode to check whether FRR is enabled.
2. Check whether VPN routing information is received from PE2 and PE3 on PE1.
3. If VPN routing information is not received, check whether MP-BGP neighbor
relationship is established successfully.

The flow to handle an L3 VPN FRR fault is shown in Figure 3-21.
3-61

Figure 3-21 Flow to Handle an L3 VPN FRR Fault

The procedure to handle an L3 VPN FRR fault is described below.
1. Check whether the FRR function is enabled. Execute the show running-config bgp
command to check whether FRR is configured in BGP private network address family
configuration mode.
2. Execute the following commands to check whether the active link and the standby link
are formed.
l show ip protocol routing vrf
l show ip forwarding route vrf
3. Check whether MP-BGP neighbor relationship is established.
4. If the fault cannot be solved according to the steps above, please ask for technical
support.
3.5 MPLS VPN Load Balancing Configuration

3.5.1 MPLS VPN Load Balancing Overview
In the existing system, there are common route transmission and label transmission by
MPLS technology. Initially, flag stack is used in LDP protocol and flag can be pushed,
3-62

replaced and popped directly. As the data flow becomes larger and larger, and the
requirement for bandwidth and time delay becomes more and more higher, the data
transmission on single link cannot satisfy the requirement. Therefore, multiple LSPs are
built, data is allocated to different links to be transmitted according to the size, and MPLS
load balancing is implemented.
MPLS VPN load balancing is divided into three parts,
l LDP
l MP-BGP
l VRF
By means of the three configurations above, the multiple routes formed load balancing in
MPLS VPN outer layer, inner layer and CE side to perform the load balancing of multiple
links in private and public networks.
According to the two policies, flow-based and destination-based, load equation, directional
and link backup.
3.5.2 LDP Load Balancing Configuration

3.5.2.1 LDP Load Balancing Overview
Since the establishment of LSP complies with IP routing protocols, MPLS load balancing
bases on the configuration of route load balancing. After configuring load balancing, create
load balancing LSP link and form MPLS load balancing label forwarding table. For the
configuration of LSP link establishment, please refer to MPLS LDP basic configuration.
3.5.2.2 LDP Load Balancing Principle

Usually, a route only have one next-hop, that is the optimum route. However, a route
can have many next-hops by means of the special configuration. There are many LSPs
between two LSRs. In this time, LDP has load balancing function. Figure 3-22 shows a
simple load balancing network structure.
Figure 3-22 LDP Load Balancing Principle
There are two possible transmission paths between PE1 and PE2.
3-63

l LSP1: PE1→P1→PE2
l LSP2: PE1→P2→PE2
Usually, the data is only transmitted along one LSP, supposing it is LSP1. However, in
some special cases, such as bandwidth restriction, congestion and so on, LDP equates
the data traffic according to the rules, allocates the data to LSP2 for forwarding, thus to
realize LDP load balancing.
3.5.2.3 Configuring LDP Load Balancing

To accomplish LDP load balancing, LDP does not need special configuration. However,
the accomplishment of LDP load balancing needs the support of routing protocol. For more
information, please refer to the maximum-paths command of routing protocol and the LDP
load balancing configuration example.
3.5.2.4 LDP Load Balancing Maintenance

ZXR10 M6000 provides the following commands to maintain LDP load balancing. The
maintenance of load balancing depends on the route next-hop and the corresponding
Forwarding Equivalence Class (FEC) label binding.
Command Function
ZXR10# show ip forwarding route This shows the route in forwarding table
and the next-hop.
ZXR10#show mpls ldp bindings [ < ip-address> { < net-mask> | < length> } [ This inspects the label binding learnt
longer-prefixes] ] [ local-label < label> [ < label> ] ] [ remote-label < label> by LDP.
[ < label> ] ] [ neighbor [ < ip-address> ] ] [ detail] instance< instance-id>
< ip-address> The destination network segment to be designated, in dotted decimal

notation
< net-mask> The network mask to be designated, in dotted decimal notation
< length> The length of mask to be designated, in the range of 0–32
longer-prefixes It shows the label binding of the network with the longest matching mask
among the networks matching designated network.
local-label < label> [ < label> ] The entries matched with the local label. Use local-label designate the
range of labels, in the range of 0–1048575.
remote-label < label> [ < label> The entries that match with the label allocated by neighbor. Use
remote-label to designate the range of labels, in the range of 0–1048575.
instance < instance-id> LDP instance number, in the range of 1–65535
An example of the show ip forwarding route command output is shown below.
3-64

ZXR10(config)#show ip forwarding route

IPv4 Routing Table:
Dest Mask Gw Interface Owner pri metric
10.10.10.0 255.255.255.0 10.10.10.1 fei-0/1/0/3 DIRECT 0 0
10.10.10.1 255.255.255.255 10.10.10.1 fei-0/1/0/3 ADDRESS 0 0
An example of the show mpls ldp bindings command output is shown below.
ZXR10(config-ldp)#show mpls ldp bindings detail instance 1
1.1.1.0/24 (no route)
remote binding: lsr: 10.10.10.2:0, label: imp-null
10.10.10.0/24
advertised to:
10.10.10.2:0
no route It shows that there is no route at local, but the peer has the route and the
label is allocated. If no this command output, it shows that local route exists.
remote binding It shows that the labels of route bound by other routers and the peer LDR.
local binding It shows that the labels of route bound by local router.
advertised to It shows the label binding information can be advertised to the LSRs of
which network segments.
3.5.2.5 LDP Load Balancing Configuration Example
As shown in Figure 3-23, there are two links between R1 and R2.
Figure 3-23 MPLS Load Balancing Configuration Example
Take the case of OSPF route load balancing, the configurations of two routers are listed
below.
Router Interface 1 and Interface 2 and Interface 3 and

Address Address Address
R1 fei-0/1/0/1 1.1.1.1 fei-0/1/0/3 2.2.2.2 loopback1 4.4.4.4
3-65

Router Interface 1 and Interface 2 and Interface 3 and

Address Address Address
R2 fei-0/1/0/1 1.1.1.2 fei-0/1/0/3 2.2.2.3 loopback1 5.5.5.5
1. Configure the IP addresses of interface on both of LSRs according to the table above.
2. Configure local OSPF rules on both of LSRs.
3. Configure mpls ldp function, and add the relevant interfaces into the LDP.
Configuration on R1:
R1(config)#interface fei-0/1/0/1
R1(config-if)#ip address 1.1.1.1 255.255.255.0
R1(config-if)#exit
R1(config-if)#exit
R1(config)#interface loopback1
R1(config-if)#exit
R1(config)#router ospf 1
R1(config-ospfv2)#network 1.1.1.1 0.0.0.255 area 0
R1(config-ospfv2)#maximum-paths 2
R1(config-ospfv2)#exit
R1(config)#mpls ldp instance 1
R1(config-ldp)#interface fei-0/1/0/1
R1(config-ldp-if)#exit
R1(config-ldp)#interface fei-0/1/0/3
R1(config-ldp-if)#exit
R2(config-if)#exit
R2(config-if)#exit
R2(config)#interface loopback1
R2(config-if)#exit
R2(config)#router ospf 1
3-66


R2(config-ospfv2)#exit
Here, the route load balancing is realized. The followed is create load equation LSP links
to realize LDP load balancing.
View route forwarding table on R1, as shown below.
IPv4 Routing Table:
1.1.1.0/24 1.1.1.1 fei-0/1/0/1 DIRECT 0 0
1.1.1.0/32 1.1.1.0 fei-0/1/0/1 MARTIAN 0 0
1.1.1.1/32 1.1.1.1 fei-0/1/0/1 ADDRESS 0 0
1.1.1.255/32 1.1.1.255 fei-0/1/0/1 BROADCAST 0 0
2.2.2.0/24 2.2.2.2 fei-0/1/0/3 DIRECT 0 0
2.2.2.0/32 2.2.2.0 fei-0/1/0/3 MARTIAN 0 0
2.2.2.2/32 2.2.2.2 fei-0/1/0/3 ADDRESS 0 0
2.2.2.255/32 2.2.2.255 fei-0/1/0/3 BROADCAST 0 0
5.5.5.5/32 2.2.2.3 fei-0/1/0/3 OSPF 110 2
5.5.5.5/32 1.1.1.2 fei-0/1/0/1 OSPF 110 2
The forwarding table shows that the network segment which destination address is
5.5.5.5/32 has two next-hops, one route pointing to 2.2.2.3 from the interface fei-0/1/0/3
and another route pointing to 1.1.1.2 from the interface fei-0/1/0/1.
Execute the show mpls ldp bindings command on R1, as shown below.
ZXR10(config)#show mpls ldp bindings instance 1

1.1.1.0/24
2.2.2.0/24
5.5.5.0/24
local binding: label: 4096
remote binding: lsr: 5.5.5.5:0, label: imp-null(inuse)(inuse)
Here, there are two tags (inuse) are encapsulated into the label pointing to 5.5.5.0/24. It
indicates that there are two session between the local and remote ends for the FEC of
5.5.5.0/24 network segment, these are two LSPs. These two LSPs are formed by the two
next-hops showing in the command output of the show ip forwarding route command.
Here, load balancing is realized. View the condition of MPLS load balancing by using
interface traffic statistic.
3-67

3.5.2.6 LDP Load Balancing Fault Handling
3.5.2.6.1 Network Topology
Take the topology shown in Figure 3-24 as an example to describe how to handle an LDP
load balancing fault.
There are two links between PE1 and PE2. Here, it is BGP route load balancing.
Figure 3-24 Network Topology of an LDP Load Balancing Fault
3.5.2.6.2 Fault Analysis
MPLS/VPN packet forwarding is LSP-based, and LSP depends on route. Therefore, the
thought of fault location is that inspect load balancing route and then inspect the labels.
1. Use the show running-config ldp command and the show running-config ospf/bgp/isis/
rip command to view the configuration of LDP load balancing.
2. Use the ping command to inspect whether the two links can be pinged.
3. Use the show ip interface brief command to inspect whether the interface is in up state.
4. Use the show ip forwarding route command to inspect whether there is a route and
whether the same IP address has two next-hops.
5. Use the show mpls forwarding-table command to inspect whether the labels exist and
whether the same IP address has two labels.
3.5.2.6.3 Handling Flow
The flow to handle an LDP load balancing fault is shown in Figure 3-25.
3-68

Figure 3-25 Flow to Handle an LDP Load Balancing Fault
3.5.2.6.4 Handling Procedure
The procedure to handle an LDP load balancing fault is described below.

1. Check whether the states of links are normal.
2. Use the show running-config ospf/isis/rip/bgp command to check whether
maximum-paths is configured in load sharing configuration.
3. Use the show ip interface brief command to check whether interfaces are up, as shown
below.
ZXR10 #show ip interface brief
3-69

gei_2/2 30.1.1.1 255.255.255.0 up up up

4. Use the ping command to inspect whether the two links can be pinged through.
ZXR10#ping 10.1.2.2
!!!!!
Success rate is 100 percent(5/5),round-trip min/avg/max= 0/0/0 ms
5. Use the show ip forwarding route command to inspect whether a route exists and
whether the route is correct.
6. Use the show ip interface brief command to inspect whether the route to the a
destination has two next hops and two egresses, as shown below.
IPv4 Routing Table:
5.5.5.0/24 2.2.2.3 gei-0/1/0/3 OSPF 10 2
5.5.5.0/24 1.1.1.2 gei-0/1/0/1 OSPF 110 2
7. Use the show mpls forwarding-table command to inspect whether all the devices in the
entity LSP already distributes the labels to the two routes with the same address.
ZXR10#show mpls forwarding-table
Local Outgoing Prefix or Outgoing Next Hop
4096 Poptag 5.5.5.0/24 gei-0/1/0/3 2.2.2.3
4097 Poptag 5.5.5.0/24 gei-0/1/0/1 1.1.1.2
3.5.3 VRF Load Balancing Configuration

3.5.3.1 VRF Load Balancing Overview
VRF load balancing is a policy that perform load balancing among multiple links in VRF
mode. Load balancing can either be realized on the basis of source and destination
address, or be realized on the basis of a packet.
Load balancing partitions the used resource to two or more parts. In normal condition,
system occupies the resource reasonably according to the actual requirements. In
abnormal condition, one part is failed, and the other parts can take over the work of the
failed part, and the communication will not be interrupted.
3.5.3.2 Configuring VRF Load Balancing

To configure VRF load balancing on ZXR10 M6000, perform the following steps.
3-70

1 ZXR10(config)#interface { < interface-name> | byname < byname> } This enters interface configuration
mode.
ZXR10(config-if)#ip load-sharing [ per-packet | per-destination ] This configures load balancing

mode.
l per-packet: load balancing
traffic is forwarded on the basis
of packets.
l per-destination: load balancing
traffic is forwarded on the basis
of destination address.
2 ZXR10(config)#ip route vrf < word> < ip-address > < net-mask> < This configures the VRF static routes
next-hop address> [ < 1-255> | global | tag] < 150-255> with different tags on PE globally.
ZXR10(config-rip)address-family ipv4 vrf < vpn-name> This enters RIP IPv4 vrf address
family mode on PE.
ZXR10(config-rip-af)maximum-paths < 1-16> This configures load balancing in

RIP IPv4 vrf address family mode on
PE.
ZXR10(config-bgp)#address-family ipv4 vrf < vpn-name> This enters BGP IPv4 vrf address
family mode on PE.
ZXR10(config-bgp-af)#maximum-paths[ ibgp] < 1-16> This configures load balancing in

BGP IPv4 vrf address family mode
on PE.
ZXR10(config-isis)#maximum-paths < 1-16> This configures load balancing in

IS-IS VRF route mode on PE.
< word> VRF name
< ip-address > Destination route address
< net-mask> Destination route mask
< next-hop address> The next hop address
< 1-255> The metric value of the destination route, in the range of 1-255
global The next-hop address is the global address
< vpn-name> VRF name
< 1-16> The number of load balancing entries to be formed
3-71

3.5.3.3 VRF Load Balancing Maintenance

ZXR10 M6000 provides the following command to maintain VRF load balancing.
Command Function
ZXR10#show ip forwarding route vrf< vrf-name> This shows the specified VPN route.
An example of the show ip forwarding route vrf command output is shown below.
ZXR10# show ip forwarding route vrf zte
IPv4 Routing Table:
Dest Gw Interface Owner pri metric
4.4.4.4/32 4.1.1.2 fei-0/1/0/3 STATIC 1 0
4.4.4.4/32 4.1.1.3 fei-0/1/0/3 STATIC 1 0
Dest Destination address
Mask Mask
Gw Gateway
Interface Interface
Owner Route type
pri Priority
metric metric range
4.4.4.4/32 4.1.1.2 There are different routes pointing to 4.4.4.4/32. That is, VRF load
4.4.4.4/32 4.1.1.3 balancing is realized.
3.5.3.4 VRF Load Balancing Configuration Example (Load Balancing on CE)
As shown in Figure 3-26, there are VRFs exist on both PE1 and PE2. The name of VRF
is zte, the RD is 1:1, the RT is 1:1. Bind the interfaces gei-/1/0/2, gei-/1/0/4 and gei-/1/0/5
to the VRF. The IP addresses of interfaces are configured as follows.
Interface IP Address
gei-/1/0/110 1.1.1/24
gei-/1/0/2 10.1.1.2/24
gei-/1/0/3 10.1.2.1/24
gei-/1/0/4 10.1.2.2/24
gei-/1/0/5 10.1.3.1/24
3-72

Interface IP Address
gei-/1/0/6 10.1.3.2/24
Figure 3-26 VRF Load Balancing Configuration Example
1. Bind the interfaces gei-/1/0/2, gei-/1/0/4 and gei-/1/0/5 to the VRF.
2. Establish IGP and LDP neighborhood between PE1 and P, and between P and PE2
respectively. Advertise loopback addresses among them.
3. Configure VRF load balancing on the interfaces gei-/1/0/1, gei-/1/0/2 and gei-/1/0/3,
gei-/1/0/4 respectively. Configure load balancing in VRF mode.
1. Establish OSPF neighborhood between CE1 and PE1.
CE1(config-if)#exit
Allocate OSPF routes and direct-connected routes in BGP IPv4 vrf address family
mode on PE1.
3-73

PE1(config-bgp-af)#redistribute connect
Configure load balancing in VRF mode on PE1.

ZXR10(config)#router ospf 10 vrf zte
ZXR10(config-ospfv2)#maximum-paths 2
2. Establish OSPF neighborhood between CE2 and PE2.
PE2 configuration,
ZXR10(config)#router ospf 10 vrf zte

ZXR10(config-ospfv2)#network 10.1.3.0 0.0.0.255 area 0
ZXR10(config-ospfv2)#redistribute bgp-int
Allocate direct-connected routes in BGP IPv4 vrf address family mode on PE2.

PE2(config-bgp-af)#redistribute connect
3. Configure load balancing on the interfaces gei-/1/0/1, gei-/1/0/2 and gei-/1/0/3,
gei-/1/0/4.
ZXR10(config)#interface gei-/1/0/1
ZXR10(config-if)#ip load-sharing per-packet
The configurations of other interfaces are the same to the above.
Use the show ip protocol routing vrf zte command to view that there are two routes
announced by CE1 to PE1 and the labels are already allocated to the routes.
ZXR10#show ip protocol routing vrf zte
Routes of vpn:

*> 20.1.1.1/32 10.1.1.1 163840 notag 0 opsf-int
*> 20.1.1.1/32 10.1.2.1 163840 notag 0 ospf-int
3.5.3.5 VRF Load Balancing Fault Handling
3.5.3.5.1 Network Topology
Take the topology shown in Figure 3-27 as an example to describe how to handle a VRF
load balancing fault.
3-74

Figure 3-27 Network Topology of a VRF Load Balancing Fault
3.5.3.5.2 Fault Analysis
The forwarding of VRF load balancing packets is route-based, so the thought of fault
location is that inspect the load balancing route.
l Use the show ip forwarding route vrf command to inspect load balancing route.
l Use the show ip protocol routing vrf command to inspect private network label.
l Use the show bgp vpnv4 unicast summary command to view MPBGP neighborhood.
View public network route. Inspect whether all the devices along the LSP path in public
network have the accurate routes pointing to the loopback addresses of the peer PEs.
View the configuration of public network IGP. Inspect whether the routes of loopback
address of PEs are allocated by IGP.
3.5.3.5.3 Handling Flow
The flow to handle a VRF load balancing fault is shown in Figure 3-28.
3-75

Figure 3-28 Flow to Handle a VRF Load Balancing Fault
3.5.3.5.4 Handling Procedure
The procedure to handle a VRF load balancing fault is described below.

1. Check whether the states of links are normal.
2. Use the show ip forwarding route vrf command to inspect the load balancing routes.
3-76

3. Use the show ip interface biref command to check whether the states of related L3
interfaces are up. Make sure that the interfaces works properly.
4. Insect the BGP configuration to view whether BGP neighbors are configured.
5. View public network labels. Use the show mpls forwarding table command to inspect
whether all the devices in the entity LSP already distribute public network labels to the
loopback addresses of the two PEs. Inspect whether the ingress label is the egress
label of the next-hop.
6. View private network labels. Use the show ip protocol routing vrf command to inspect
whether the private network label of the local PE router is distributed by the peer PE.
7. If labels are not distributed correctly, view LDP neighborhood. Use the show mpls ldp
neighbor command to inspect whether LDP neighborhood is established between two
adjacent PEs or P routers. The information State: Oper means that LDP neighborhood
is established between the adjacent routers successfully.
8. Inspect MBGP configuration and the route protocol configuration between PE and
CE. In each VRF, inspect whether the VRF route is distributed to BGP. It is necessary
to configure the address-family ipv4 vrf command and the redistribute connected
command. For a common neighbor, check whether it can forwards vpnv4 routes.
9. View MPLS configuration. Use the show running-config ldp command to inspect
whether MPLS is enabled globally and on the related interfaces.
3-77

3-78

Chapter 4
Multicast VPN Configuration
Table of Contents
VPN Multicast Overview .............................................................................................4-1
VPN Multicast Principle ..............................................................................................4-1
Configuring VPN Multicast..........................................................................................4-1
VPN Multicast Maintenance........................................................................................4-3
VPN Multicast Configuration Example ........................................................................4-9
VPN Multicast Fault Handling ...................................................................................4-15
4.1 VPN Multicast Overview

Multicast VPN is a technology that supports multicast services on the base of BGP/MPLS
IP VPN. This technology accomplishes the multicast data transport between private
networks by encapsulating private network multicast packets and transmitting them on
the multicast tunnels established between sites.
4.2 VPN Multicast Principle

Multicast VPN enables multicast service on the base of current MPLS/BGP VPN. It
completes the function of transmitting multicast data between private networks by
encapsulating the original multicast data. On the original multicast technology base,
multicast VPN technology solves the following problems: How public network does RPF
inspection to forward multicast data when public network does not know private network.
Private network source address and destination address are overlapped. How private
network multicast data flow is forwarded to private site. Multicast VPN implements
ordinary multicast function on private network and ordinary multicast function on public
network. It implements that public network forwards multicast data of private network and
multicast data is not flooded on public network but is forwarded according to requirement.
At present, it is the PIM-SM protocol which is used most widely.
4.3 Configuring VPN Multicast

To configure VPN multicast, perform the following steps.
1 ZXR10(config)#ip multicast-routing This enables IP multicast route

function.
4-1

2 ZXR10(config-mcast)#router pimsm Only enable pimsm and then

exit pimsm, can VRF mode be
configured.
3 ZXR10(config-pimsm)#exit This exits from pimsm mode.
4 ZXR10(config-mcast)#vrf < vrf-name> This enters multicast VRF mode.
5 ZXR10(config-mcast-vrf)#mtunnel < interface-name> This configures one interface as an

mtunnel interface.
6 ZXR10(config-mcast-vrf)#mdt default < group-address> This configures a MDT default group

of a multicast instance.
7 ZXR10(config-mcast-vrf)#mdt data < group-address> < This configures MDT data group of
group-mask> [ < acl-name> ] multicast instance.
8 ZXR10#clear ip mroute [ < vrf-name> ] [ group-address < This clears multicast route.
group-address> ] [ source-address < source-address> ]
9 ZXR10(config-pimsm-vrf)#static-rp < ip-address> [ group-list < This configures a static Rendezvous

prefix-list-name> ] [ priority < priority> ] Point (RP).
10 ZXR10(config-pimsm-vrf)#no static-rp This deletes static RP.
11 ZXR10(config-pimsm-vrf)# bsr-candidate < interface-name> [ < This configures a candidate

hash-mask-length> ] [ < priority> ] Bootstrap Router (BSR).
12 ZXR10(config-pimsm-vrf)# rp-candidate < interface-name> [ This configures a candidate RP.

group-list < prefix-list-name > ] [ priority < priority> ]
13 ZXR10(config-pimsm-vrf)#interface < interface-name> This configures a multicast Protocol

Independent Multicast - Sparse
Mode (PIM-SM) interface.
14 ZXR10(config-pimsm-vrf-if)#pimsm This enables multicast route protocol

PIM-SM on the interface.
< vrf-name> VRF name, with 1-32 characters
< group-address> MDT default group address of VRF instance
4-2

Chapter 4 Multicast VPN Configuration
Parameters Description
< group-address> MDT data group address of VRF instance
< group-mask> MDT data group mask of VRF instance (inverse mask)
< acl-name> MDT data group address range
< group-address> Group address, in dotted decimal notation
< source-mask> Source address, in dotted decimal notation
< ip-address> IP address
< prefix-list-name> Prefix list name, with 1-31 characters
< priority> Priority, 0-255, the default value is 192
< interface-name> Interface name
< hash-mask-length> Hash length, 0-32, the default is 30
< priority> Priority, in the range of 0-255, with the default value 0
< interface-name> Interface name
< prefix-list-name> Prefix list name, with 1-31 characters
< priority> Priority, in the range of 0-255, with the default value 192
4.4 VPN Multicast Maintenance

ZXR10 M6000 provides the following commands to maintain VPN multicast.
Command Function
ZXR10#show ip mroute summary [ < vrf-name> ] This views the detailed number of IP
multicast route table.
4-3

Command Function
ZXR10#show ip pimsm mroute [ < vrf-name> ] [ group < group-address> ] [ This views the content of multicast
source < source-address> ] PIM-SM route table.
ZXR10#show ip pimsm rp mapping [ < vrf-name> ] This views RP information.
ZXR10#show ip pimsm bsr [ < vrf-name> ] This views BSR information.
ZXR10#show ip pimsm rp hash [ < vrf-name> ] < group-address> This views the RP information selected
by specified multicast group.
ZXR10#show ip pimsm interface [ < vrf-name> ] [ < interface-name> This views interface state of PIM-SM.
ZXR10#show ip pimsm neighbor [ < vrf-name> ] [ < interface-name> ] This views neighbor state of PIM-SM
interface.
ZXR10#show ip pimsm rpf [ < vrf-name> ] < source-address> This views multicast PIM-SM Reverse
Path Forwarding (RPF) information.
< group-address> Group address, in dotted decimal notation
< source-address> Source address, in dotted decimal notation
l An example of the show ip mroute [ < vrf-name> ] [ group < group-address> ] [ source
< source-address> ] command output is shown below.
ZXR10#show ip mroute vrf test
IP Multicast Routing Table
(*, 225.1.1.1), RP: 1.1.1.1, TYPE: DYNAMIC, FLAGS: MT
Incoming interface: NULL, flags:
Outgoing interface list:
loopback1, flags: MT
(1.1.1.1, 225.1.1.1), RP: 1.1.1.1, TYPE: DYNAMIC, FLAGS:
Incoming interface: loopback1, flags:
l An example of the show ip rpf[ < vrf-name> ] < source-address> command output is
shown below.
ZXR10#show ip rpf vrf test 1.1.1.1
pimsm RPF information:
RPF interface is loopback1 (pimsm)
RPF neighbor is 1.1.1.1 (local)
RPF metric preference is 0
RPF metric value is 0
RPF type is unicast
l An example of the show ip mdt command output is shown below.
ZXR10#show ip mdt
4-4

cyl MDT information:

MTunnel is: loopback1 1.1.1.1(PIMSM and BGP ok)
Default group is: 225.1.1.1
Data group is:
l An example of the show ip mroute summary [ < vrf-name> ] command output is shown
below.
ZXR10#show ip mroute summary vrf test
IP multicast routing table summary
(*,G): 1 routes
(S,G): 1 routes
Total: 2 routes
l An example of the show ip mroute brief [ < vrf-name> ] command output is shown
below.
ZXR10#show ip mroute brief vrf test
IP Multicast Routing Table Brief
(*, 225.1.1.1), TYPE: DYNAMIC
(1.1.1.1, 225.1.1.1), RP: 1.1.1.1, TYPE: DYNAMIC
l An example of the show ip pimsm mroute [ < vrf-name> ] [ group < group-address> ] [
source < source-address> ] command output is shown below.
ZXR10(config)#show ip pimsm mroute vrf test
PIMSM Multicast Routing Table
Flags: T- SPT-bit set,A- Forward,J- Join SPT,U- Upsend ,
Macro state: Ind- Pim Include Macro,Exd- Pim Exclude Macro,
Jns- Pim Joins Macro,LAst- Pim Lost_assert Macro,
Imo- Pim Immediate_olist Macro,Ino- Pim Inherited_olist Macro,
Lcd- Pim Local_receiver_include Macro
Timers:Uptime/Expires(Upstream State)
(*, 224.0.1.40), 00:01:18/00:00:00(JOINED), RP address: 0.0.0.0,
Ind: 1/Jns: 0/LAst: 0/Imo: 1/Lcd: 1
Iif: NULL, RPF nbr: 0.0.0.0
Oif:
fei-0/1/0/1, LocalIn / ImoXG
Ind: 1/Jns: 0/LAst: 0/Imo: 1/Lcd: 1
Iif: NULL, RPF nbr: 0.0.0.0
Oif:
fei-0/1/0/2, LocalIn / ImoXG
Connected Specify direct-connect member is available in the multicast group or on

the interface
Pruned There is no next-hop for this entry
RP-bit set It indicates this (S,G) entry is available in RPT
4-5

Register flag It indicates this entry can send Register message from directly connected
multicast source.
SPT-bit set It indicates the route entry receives a multicast packet sent from SPT
Up Send It indicates multicast packet is up-sent to this entry.
Join SPT It indicates the received data flow is switched to SPT.
Uptime/Expires It indicates the uptime and expiring time of entry/outgoing interface.
RP The corresponding RP of (*G) entry generated by PIM-SM
flag Multicast route entry state
Incoming interface: Entry incoming interface
RPF nbr Entry corresponding RPF neighbor
Outgoing interface list Outgoing interface list
l An example of the show ip pimsm rp mapping [ < vrf-name> ] command output is shown
below.
ZXR10#show ip pimsm rp mapping
Group(s): 224.0.0.0/4(SM)
RP: 1.1.1.1, v2, Priority:192
BSR: 1.1.1.1, via bootstrap
Uptime: 00:13:18, expires: 00:01:02
Group(s): 0.0.0.0/0(NOUSED)
Group BSR advertisement multicast group address and mask
Rp address Candidate RP address, version and priority of this multicast group

advertisement
static It indicates that this candidate RP is not BSR advertisement but local
static configuration.
BSR address BSR IP address
uptime Lifetime of candidate RP
expire Expired time of candidate RP
l An example of the show ip pimsm bsr [ < vrf-name> ] command output is shown below.
ZXR10#show ip pimsm bsr vrf test
BSR address: 1.1.1.1

Uptime: 03:37:31, BSR Priority :0, Hash mask length:0
4-6

Expires:00:00:04
This system is a candidate BSR!

candidate BSR address: 1.1.1.1(loopback1),
priority: 0,
hash mask length: 0
This system is a candidate RP!

candidate RP address: 1.1.1.1(loopback1),priority:192
BSR address IP address of BSR
Uptime Lifetime of BSR
BSR Priority BSR priority
Hash mask length BSR mask length
Expires BSR expired time or the expired time of sending BSR message.
candidate BSR address IP address of candidate BSR configured locally
Priority Priority of candidate BSR configured locally
hash mask length Mask length of candidate BSR configured locally
CRP IP address, interface number and priority of candidate RP configured locally
l An example of the show ip pimsm rp hash [ < vrf-name> ] < group-address> command
output is shown below.
ZXR10(config-pimsm)#show ip pimsm rp hash 224.0.1.40 vrf test
rp address: 1.1.1.10
rp address It specifies RP address specified by multicast group.
l This example describes what will be output after show ip pimsm interface [ < vrf-name>
] [ < interface-name> ] is implemented.
ZXR10(config-pimsm)#show ip pimsm interface vrf test
Address Interface State Nbr Hello DR DR
Count Period Priority
1.1.1.10 fei-0/1/0/1 Up 1 30 1 1.1.1.10
2.2.2.10 fei-0/1/0/2 Up 0 30 1 2.2.2.10
Descriptions of command output are shown below.
4-7

show Command Output Description
Address Interface address
Interface Interface name
NbrCount neighbor number
State Interface state is up/down
QueryIntvl The sending time interval of HELLO message
DR Prio DR priority of this interface
DR DR of this interface
l This example describes what will be output after show ip pimsm neighbor [ < vrf-name>
] [ < interface-name> ] is implemented.
ZXR10(config)#show ip pimsm neighbor vrf test
Neighbor Address Interface DR Priority Uptime Expires Ver
1.1.1.1 fei-0/1/0/1 1 00:15:08 00:01:24 V2
Neighbor Address Neighbor IP address
Interface Interface name
DR Prio Neighbor DR priority
Uptime Neighbor lifetime
Expires Neighbor expired time
Ver Version number
l This example describes what will be output after show ip pimsm rpf [ < vrf-name> ] <
source-address> is implemented.
ZXR10(config)#show ip pimsm rpf vrf test 1.1.1.10
RPF information:
RPF interface is fei-0/1/0/1(pimsm)
RPF neighbor is 1.1.1.10(local)
RPF metric preference is 0
RPF metric value is 0
RPF interface RPF interface to multicast source address
RPF neighbor RPF neighbor to multicast source address
RPF metic preference Route preference to multicast source address
RPF metric Route metric to multicast source address
4-8

4.5 VPN Multicast Configuration Example

This example implements basic function configuration of multicast VPN to make private
network multicast data to be transmitted, as shown in Figure 4-1.
Figure 4-1 Multicast VPN Configuration Example
1. Configure MPLS VPN enviroment.
2. Configure public network multicast and private network multicast on PE1.
3. Configure public network multicast on P.
4. Configure public network multicast and private network multicast on PE2.
1. Configure MPLS VPN enviroment.
l Configuration on PE1:
PE1(config-if)#exit
PE1(config-if)#exit
4-9

PE1(config)#ip vrf test
PE1(config-vrf)#route-target 10:10
PE1(config-if)#ip vrf forwarding test
PE1(config-if)#exit
/*Here loopback interface is used to establish BGP neighbor relationship.*/
PE1(config-bgp)#neighbor 1.1.1.19 activate
PE1(config-bgp)#address-family ipv4 vrf test
l Configuration on P:
P (config)#interface loopback1
P(config-if)#exit
P(config-if)#exit
P(config-if)#exit
P(config-ospfv2)#network 1.1.1.18 0.0.0.0 area 0
P(config)#mpls ldp
P(config-ldp)#exit
l Configuration on PE1 (the same as that on PE1):
PE2(config-if)#exit
4-10

PE2(config-if)#exit
PE2(config)#ip vrf test
PE2(config-vrf)#route-target 10:10
PE2(config-if)#ip vrf forwarding test
PE2(config-if)#exit
PE2(config-bgp)#neighbor 1.1.1.17 activate
PE2(config-bgp)#address-family ipv4 vrf test
2. Configure multicast on PE1.
l Configure public network multicast.
PE1(config)#ip multicast-routing
PE1(config-mcast)#router pimsm
PE1(config-pimsm)#interface loopback1
PE1(config-pimsm-if)#pimsm
PE1(config-pimsm-if)#exit
PE1(config-pimsm)#interface gei-0/1/0/1
PE1(config-pimsm)#rp-candidate loopback1
/*Public network must have one RP and can have many for election.*/
PE1(config-pimsm)#bsr-candidate loopback1
PE1(config-pimsm)#exit
l Configure private network multicast.
PE1(config-mcast)#vrf test
4-11

PE1(config-mcast-vrf)#router pimsm
PE1(config-pimsm-vrf)#interface fei-0/1/0/3
PE1(config-pimsm-vrf-if)#pimsm
PE1(config-pimsm-vrf-if)#exit
PE1(config-pimsm-vrf)#rp-candidate fei-0/1/0/3
/*Private network must have RP*/
PE1(config-pimsm-vrf)#bsr-candidate fei-0/1/0/3
PE1(config-pimsm-vrf)#exit
PE1(config-mcast-vrf)#mdt default 235.1.1.1
/*The configurations of mdt on PE1 and PE2 must be same.*/
PE1(config-mcast-vrf)#mdt data 239.1.1.1 0.0.0.0
PE1(config-mcast-vrf)#mtunnel loopback1
/*mtunnel interface must be loopback interface and must be BGP link setup
interface.*/
PE1(config-mcast-vrf)#exit
PE1(config-mcast)#exit
PE1(config)#
3. Configure multicast on P.
P(config)#ip multicast-routing
P(config-mcast)#router pimsm
P(config-pimsm)#interface gei-0/1/0/1
P(config-pimsm-if)#pimsm
P(config-pimsm-if)#exit
P(config-pimsm)#interface gei-0/1/0/2
P(config-pimsm-if)#pimsm
P(config-pimsm-if)#exit
4. Configure multicast on PE2.
l Configure public network multicast.
PE2(config)#ip multicast-routing
PE2(config-mcast)#router pimsm
PE2(config-pimsm)#interface loopback1
PE2(config-pimsm)#interface gei-0/1/0/1
PE2(config-pimsm)#exit
l Configure private network multicast.
PE2(config-mcast)#vrf test
PE2(config-mcast-vrf)#router pimsm
PE2(config-pimsm-vrf)#interface fei-0/1/0/3
PE2(config-pimsm-vrf-if)#pimsm
PE2(config-pimsm-vrf-if)#exit
PE2(config-pimsm-vrf)#exit
PE2(config-mcast-vrf)#mdt default 235.1.1.1
4-12

/*The configurations of mdt on PE1 and PE2 must be same.*/

PE2(config-mcast-vrf)#mdt data 239.1.1.1 0.0.0.0
PE2(config-mcast-vrf)#mtunnel loopback1
/*mtunnel interface must be loopback interface and must be BGP link setup
interface.*/
l Receiver group is added.
PE2(config-mcast-vrf)#router igmp
/*here receiver can select static group to add or dynamic group to add.*/
PE2(config-igmp-vrf)#interface fei-0/1/0/3
PE2(config-igmp-vrf_if)#static-group 225.0.0.1
PE2(config-mcast-vrf)#exit
PE2(config-mcast)#exit
PE2(config)#
When MPLS VPN is established, execute the show ip forwarding route vrf test command
on PE1 and PE2, as shown below.
PE1(config)#show ip forwarding route vrf test
IPv4 Routing Table:
100.106.102.0/24 1.1.1.19 gei-0/1/0/1 BGP 200 0
100.105.102.0/24 100.105.102.17 fei-0/1/0/1 DIRECT 0 0
100.105.102.0/32 100.105.102.0 fei-0/1/0/1 MARTIAN 0 0
100.105.102.17/32 100.105.102.17 fei-0/1/0/1 ADDRESS 0 0
100.105.102.17/32 100.105.102.17 fei-0/1/0/1 BROADCAST 0 0
224.0.0.0/4 224.0.0.0 NULL MULTICAST 0 0
224.0.0.0/24 224.0.0.0 NULL MULTICAST 0 0
PE1#ping vrf test 100.106.102.17

!!!!!
1. View public network neighbor establishment state, as shown below.
PE1#show ip pimsm neighbor
17.81.1.17 gei-0/1/0/1 1 00:06:48 00:01:20 V2
2. View private network neighbor establishment state, as shown below.
PE1#show ip pimsm neighbor vrf test
1.1.1.17 loopback1 1 00:03:28 00:01:17 V2
3. View public network multicast interface state, as shown below.
PE1#show ip pimsm interface
4-13

1.1.1.81 loopback1 Up 0 30 1.1.1.81 1

17.81.1.81 gei-0/1/0/1 Up 1 30 17.81.1.81 1
4. View private network multicast interface state, as shown below.
PE1#show ip pimsm interface vrf test
1.1.1.81 loopback1 Up 1 30 1.1.1.81 1
111.83.83.1 fei-0/1/0/1 Up 0 30 111.83.83.1 1
5. View public network RP, as shown below.
PE1#show ip pimsm rp mapping
Group(s): 224.0.0.0/4(SM)
RP: 1.1.1.17, v2, Priority:192
Uptime: 00:13:27, expires: 00:02:03
6. View private network RP, as shown below.
PE1#show ip pimsm rp mapping vrf test
Group(s): 224.0.0.0/4(SM)
RP: 111.17.17.1, v2, Priority:192
Uptime: 00:08:17, expires: 00:02:13
7. View public network BSR, as shown below.
PE1#show ip pimsm bsr

Expires:00:01:40
No candidate RP information
8. View privae network BSR, as shown below.
PE1#show ip pimsm bsr vrf lyq

Expires:00:01:55
No candidate RP information!
9. View public route. Check whether public network and private network routes are
generated correctly.
ZXR101#show ip mroute
IP Multicast Routing Table
(*, 235.1.1.1), RP: 1.1.1.17, TYPE: DYNAMIC, FLAGS: NS/MT
Incoming interface: gei-0/1/0/1, flags: NS
4-14

(1.1.1.17, 235.1.1.1), RP: 1.1.1.17, TYPE: DYNAMIC, FLAGS: MT

Incoming interface: gei-0/1/0/1, flags:
(1.1.1.81, 235.1.1.1), RP: 1.1.1.17, TYPE: DYNAMIC, FLAGS:
Incoming interface: loopback1, flags:
gei-0/1/0/1, flags: F
ZXR101#show ip pimsm mroute

PIMSM Multicast Routing Table
Flags: T- SPT-bit set,A- Foward,J- Join SPT,U- Upsend ,
Macro state:Ind- Pim Include Macro,Exd-Pim Exclude Macro,
Jns-Pim Joins Macro,LAst Pim Lost_assert Macro,
Imo-Pim Immediate_olist Macro,Ino-Pim Inherited_olist Macro,
Lcd-Pim Local_receiver_include Macro
Timers:Uptime/Expires(Upstream State)
Include: 1/Joins: 0/Lost_Ast: 0/Im_Olist: 1/Local_include: 1
Iif: int1, RPF nbr: 17.81.1.17, AJ
Oif:
loopback1, LocalIn / CouldAst / AstTr / ImoXG
(1.1.1.17, 235.1.1.1), 00:10:14/00:00:46(JOINED)/00:02:56,
Reg:NO INFO; RP:1.1.1.17; RT:NULL;
Ind:0/Exd:0/Jns:0/LAst:0/Imo:0/Ino:1
Iif: gei-0/1/0/1, RPF nbr:17.81.1.17; AT
Oif:
loopback1, InheriedFromXG / InoSGRpt / InoSG
(1.1.1.81, 235.1.1.1), 00:15:34/00:00:00(JOINED)/00:02:22,
Reg:PRUNE; RP:1.1.1.17; RT:NULL;
Ind:0/Exd:0/Jns:1/LAst:0/Imo:1/Ino:2
Iif: loopback1, RPF nbr:0.0.0.0; AT
(1.1.1.81, 235.1.1.1, rpt), 00:15:34/00:00:00(PRUNED),
Pru:0/LAst:0/Ino:1
Iif:int1; RPF nbr:17.81.1.17(RPF'(*, G));
Oif:
loopback1, AstTrSG / InheriedFromXG / InoSGRpt / InoSG
gei-0/1/0/1, JoinsSG / AstTrSG / InoSG
4.6 VPN Multicast Fault Handling

4.6.1 Network Topology
The network topology of a VPN multicast fault is shown in Figure 4-2.
4-15

Figure 4-2 Network Topology of a VPN Multicast Fault
4.6.2 Fault Analysis

Symptom: create multicast VPN environment, receiver group sends IGMP group join
request to PE2, multicast source sends flow to this group but flow is not through.
Possible causes:
1. L3VPN environment is not set completely.
2. PIM-SM neighbor of public network is not established.
3. The multicast routing table of the public network is not formed.
4. PIM-SM neighbor of private network is not established.
5. (*,G) and (S,G) route of private network is not formed.
4.6.3 Handling Flow

The flow to handle a VPN multicast fault is shown in Figure 4-3.
4-16

Figure 4-3 Flow to Handle a VPN Multicast Fault
4.6.4 Handling Procedure

The procedure to handle a VPN multicast fault is described below.
4-17

1. Check whether L3VPN environment is set successfully, if it redistributes the direct

connecting routing in private network, if the private routing of peer site is learnt.
2. Check whether loopback address of L3VPN link setup of PE1 and PE2 is added into
public multicast.
3. Check whether direct connecting interface between PEs is joined public network
multicast.
4. Check whether public network configures RP. For special group, the whole multicast
network only has one RP.
5. Check whether mtunnel is configured and if it is BGP link set interface.
6. Check whether MDT default is configured and this configuration must be done.
7. Check wether it receives the Internet Group Management Protocol (IGMP) report.
8. Check whether the destination group of flow is same as request group.
4-18

Chapter 5
L2TP Configuration
Table of Contents
L2TP Overview...........................................................................................................5-1
L2TP Principle............................................................................................................5-2
Configuring L2TP .......................................................................................................5-8
L2TP Maintenance ...................................................................................................5-11
L2TP Configuration Examples ..................................................................................5-14
L2TP Fault Handling.................................................................................................5-19
5.1 L2TP Overview

Layer2 Tunneling Protocol (L2TP) is a type of Virtual Private Dialup Network (VPDN)
tunneling protocol.
VPDN is to access a public network by using the dialing function of the public network
(such as Integrated Services Digital Network (ISDN) and Public Switched Telephone
Network (PSTN)) to accomplish a virtual private network, thus providing access services
for enterprises, ISPs and mobile office staff. That is to say, VPDN provides an economical
and effective point-to-point connection mode between remote a user and a private
enterprise network.
VPDN uses a special network communication protocol to construct a secure virtual private
network on a public network. Mobile office staff can connect to the enterprise headquarters
through the virtual tunnel and the public network. Other users on the public network cannot
go through the virtual tunnel and access the resources inside the enterprise network.
There are two modes to accomplish VPDN.
l An Network Access Server (NAS) starts establishing a VPDN connection.
The NAS connects a PPP connection of a user to the VPDN gateway of the
enterprise through a VPDN tunneling protocol, thus establishing a tunnel with the
VPDN gateway. This is invisible for the user. The user only needs to log in once to
access the enterprise network. The enterprise network authenticates the user and
allocates a private address instead of a public address. In this mode, the NAS needs
to support VPDN and the authentication system needs to support the VPDN attribute.
l A user starts establishing a VPDN connection.
The client of the user establishes a tunnel with the VPDN gateway. In this mode, the
client establishes a connection with the Internet first, and then the client establishes
a tunnel with the VPDN gateway through a special program (such as the L2TP client
supported by Windows 2000). The method which the user uses to connect to the
5-1

Internet and the place where the user connects to the Internet are not restricted. No
ISP is involved. However, the user needs to install a special program (generally on
the Windows 2000 platform), which restricts the platform the user uses.
Generally, the VPDN gateway is a router or a VPDN private server.
There are three VPDN tunneling protocols.
l PPP Tunnel Protocol (PPTP)
l Layer 2 Forwarding (L2F)
l L2TP
At present, L2TP is the most widely used.
L2TP was drafted by IETF. Corporations including Microsoft, Ascend, Cisco and 3COM
instituted the protocol. L2TP integrates the advantages of PPTP and L2F. It is accepted by
many corporations, and it has become the L2 tunneling protocol-related industrial standard
of IETF.
L2TP has the following features.
l L2TP is suitable for an individual user or several users to access an enterprise

network. The point-to-network characteristic is stipulated by its bearer protocol, that
is, PPP.
l L2TP encapsulates a packet of a private network, so the network address of this
packet is transparent when the packet is transmitted on the Internet. Inside dynamic
address allocation for access users is supported.
l Cooperating with the PPP module, L2TP supports local and remote Authentication,
Authorization and Accounting (AAA) functions. For a user access, L2TP can identify
whether a user is a VPN user according to the full username, user domain name or
the special service number that the user uses for accessing.
l For packet security, L2TP uses IP Security Protocol (IPSec). With IPsec, packets can
be encrypted before the packets are sent to the Internet. The user control mode can
use encryption at the L2TP Access Concentrator (LAC) side of the VPN end system,
that is, the ISP control mode.
l For a dial-up service user, VPN dialing software can be configured to start establishing
a connection from the user to the private enterprise network directly. In this way, the
user can determine whether VPN service is needed when getting online.
5.2 L2TP Principle

5.2.1 L2TP Network Structure
There are three L2TP access modes, as shown in Figure 5-1.
5-2

Chapter 5 L2TP Configuration
Figure 5-1 Three L2TP Access Modes
This figure shows three common construction modes of L2TP. It also shows the three
essentials to construct an L2TP network: an L2TP Network Server (LNS), an LAC and a
client.
l LNS: It is the VPN server at the L2TP enterprise side. The server is responsible for
final authorization and authentication for users, receiving the tunnel and connection
requests from an LAC, and establishing PPP tunnels connecting the LNS and users.
l LAC: It is an L2TP access device. It provides AAA service for different types
of user accesses, starts the connection establishment of a tunnel or a session,
and accomplishes the proxy authentication for VPN users. It is an access device
providing VPN service at the ISP side. In physical, it can be a router on which L2TP
is configured, an access server or a special VPN server.
5.2.2 L2TP Function Overview

Figure 5-2 shows the position of L2TP in the whole Transfer Control Protocol/Internet
Protocol (TCP/IP) hierarchic structure. It also shows the protocol stack structure and
encapsulation procedure of an IP packet during its transmission procedure.
5-3

Figure 5-2 L2TP Encapsulation
Take the transmission procedure of an IP packet at the user side as an example to describe
the VPN working principle. The IP marked yellow is user data that a user wants to send.
At the LAC side, the LAC adds a PPP header to the user packet at the link layer and then
sends it to L2TP. Then the LAC encapsulates the L2TP packet into a UDP packet and
then encapsulates it into an IP packet that can be transmitted on the Internet. The result is
that there is one more IP address in the IP packet, and the two IP addresses are different.
Generally, the IP address of a user packet is a private address, and the IP address on the
LAC is a public address. The encapsulation of VPN private data is finished.
At the LNS side, after receiving an L2TP/VPN IP packet, the LNS removes the IP header,
the UDP header and the L2TP header and then restores the user PPP packet. The LNS
removes the PPP header and obtains an IP packet. In this way, the IP data is transmitted
through a tunnel transparently. The PPP header/packet is unchanged during the whole
transmission procedure. This verifies that L2TP is an L2 VPN tunneling protocol.
5.2.3 L2TP Negotiation Procedure

To transmit a packet between a VPN user and a server, it is necessary to establish a
tunnel and a session between the LAC and the LNS. The tunnel is defined according
to the attributes of a connection that can be shared by a group of users with the same
session connection characteristics. A session is a PPP data tunnel that is established for
the connection of a user and the enterprise VPN server. Multiple session reuse a tunnel.
A tunnel or a session is established and deleted dynamically.
5.2.3.1 L2TP Tunnel and Session Establishment Flow

The L2TP tunnel and session establishment flow is shown in Figure 5-3.
5-4

Figure 5-3 L2TP Tunnel and Session Establishment Flow
L2TP tunnel establishment is a three-way procedure. First, the LAC sends an SCCRQ.
After receiving the request, the LNS replies with an SCCRP. At last, the LAC sends an
SCCCN after receiving the reply. A tunnel is established.
The procedure to establish a session is similar to the procedure to establish a tunnel. First,
the LAC sends an ICRQ. After receiving the request, the LNS replies with an ICRP. The
LAC sends an ICCN after receiving the replay. A session is established.
5.2.3.2 L2TP Tunnel Maintenance

The L2TP tunnel maintenance flow is shown in Figure 5-4.
5-5

Figure 5-4 L2TP Tunnel Maintenance
After a tunnel is established, it will be torn down until all sessions on this tunnel are offline.
To confirm that the tunnel structure a the remote end still exists, it is necessary to send
maintenance packets to the remote end periodically. The flow is: The LAC (or the LNS)
sends a Hello packet, and the LNS (or the LAC) sends an acknowledgement packet.
5.2.3.3 L2TP Tunnel and Session Backout Flow

The L2TP tunnel and session backout flow is shown in Figure 5-5.
Figure 5-5 L2TP Tunnel and Session Backout Flow
5-6

The tunnel backout flow is simpler than the tunnel establishment flow. Either end of a tunnel
sends a StopCCN, and the other end sends an acknowledgement. The session backout
flow is: Either end sends a session CDN, and the other end sends an acknowledgement.
5.2.4 LTS Function Overview

L2TP can make the handling of a PPP packet be separated from the L2 circuit terminal.
L2TP tunnel switching can make the terminal of a PPP session be moved to another farther
LSN that may be unknown for the first LAC. This accomplished by using another L2TP
tunnel to transmit the PPP session to another LNS.
Figure 5-6 shows a typical situation of an incoming tunnel switching. A user starts a PPP
session on an LAC. The LAC transmits this L2 session to a TSA through an L2TP tunnel.
The TSA first works as an LNS to establish a tunnel with the LAC at the user side. Then the
TSA determines whether to terminate this PPP session locally or to use a second tunnel to
continue transmitting this PPP session according to the local policy. If the TSA determines
to use a second tunnel to continue transmitting this PPP session, the TSA works as an
LAC again to establish a tunnel with the LNS at the server end. It switches the same PPP
session to the L2TP tunnel that starts from the TSA and ends on the LNS.
Figure 5-6 Typical LTS
An LTS application is shown in Figure 5-7.
Figure 5-7 Typical L2TP LTS Application Network Structure
5-7

5.3 Configuring L2TP

To configure L2TP VPDN on ZXR10 M6000, perform the following steps.
1 ZXR10(config)#vpdn This enters VPDN configuration

mode.
2 ZXR10(config-vpdn)#enble This enables the VPDN function.
3 ZXR10(config-vpdn)#default vpdn-group < group-name> This configures the group name of

the default VPDN group.
ZXR10(config-vpdn)#radius vpdn-group < group-name> This configures the group name of

the default VPDN group of RADIUS.
ZXR10(config-vpdn)#tunnel-create-by-vpdngroup This establishes a tunnel according

to a VPDN group.
ZXR10(config-vpdn)#multihop This enables LTS.
ZXR10(config-vpdn)#tsa-id < name> This configures the name on an LTS

node.
< group-name> The group name of the default VPDN group, 1-31 characters
< name> The name on the LTS node, 1-64 characters
To configure an L2TP VPDN group on ZXR10 M6000, perform the following steps.
1 ZXR10(config)#vpdn-group < group-name> This creates a VPDN group and

enters VPDN group configuration
mode.
2 ZXR10(config-vpdn-group)#proxy-authentication This enables the L2TP proxy

authentication function.
ZXR10(config-vpdn-group)#force-local-chap This uses the CHAP authentication

mode compulsively.
ZXR10(config-vpdn-group)#l2tp hidden This controls to hide the AVPs when

a packet is sent.
ZXR10(config-vpdn-group)#l2tp sequencing This configures to use a sequence

number when a packet is sent.
ZXR10(config-vpdn-group)#l2tp tunnel hello < hello-time> This configures the keep-alive time
of a tunnel.
5-8

ZXR10(config-vpdn-group)#l2tp tunnel authentication This enables authentication during

tunnel negotiation.
ZXR10(config-vpdn-group)#l2tp tunnel password < password> This configures an authentication

password of a tunnel.
ZXR10(config-vpdn-group)#l2tp tunnel receive-window < size> This configures the size of the
window where to receive the tunnel
control packets.
ZXR10(config-vpdn-group)#l2tp tunnel retransmit retries < times> This configures the maximum times
of retransmission retries of tunnel
control packets.
ZXR10(config-vpdn-group)#l2tp tunnel retransmit timeout < time> This configures the retransmission
time-out time of tunnel control
packets.
ZXR10(config-vpdn-group)#l2tp tunnel timeout setup < time> This configures the setup time-out
time of a tunnel.
ZXR10(config-vpdn-group)#l2tp tunnel timeout no-session < time> This configures the time-out time of
deleting a tunnel when there is no
session on the tunnel.
ZXR10(config-vpdn-group)#lns-send-sli This enables the LNS to send SLI

packets.
ZXR10(config-vpdn-group)#lcp renegotiation { disable | always This configures a renegotiation

| on-mismatch} policy on an LNS.
ZXR10(config-vpdn-group)#local name < local-name> This configures the local name of a

tunnel.
ZXR10(config-vpdn-group)#source-ip-addr < ip-address> This configures the source address

of a tunnel.
ZXR10(config-vpdn-group)#initiate-to-ip-addr < ip-address> [ This configures the peer-end

priority < priority> ] address of a tunnel.
ZXR10(config-vpdn-group)#service-type { lac | lns } This configures the service type of a

VPDN group.
ZXR10(config-vpdn-group)#new-random This configures each AVP that a you

want to hide to use a new random
number in the control packets.
ZXR10(config-vpdn-group)#virtual-template < template-no> This binds the VPDN group to a

specific virtual template.
ZXR10(config-vpdn-group)#max-session < num> The configures the maximum

number of L2TP sessions that are
allowed to access the VPDN group.
5-9

ZXR10(config-vpdn-group)#max-session-per-tunnel < num> The configures the maximum

number of L2TP sessions that are
allowed in the tunnel where the
VPDN group locates.
ZXR10(config-vpdn-group)#domain < domain-name> This uses the VPDN group to

establish a domain.
ZXR10(config-vpdn-group)#terminate-from hostname < hostname> This configures the local name of the
peer-end of a tunnel.
< group-name> The group name of the default VPDN group, 1-31 characters
< hello-time> The keep-alive time of a tunnel, range: 1-3600 seconds
< password> The authentication password of a tunnel, 1-31 characters
< size> The number of tunnel control packets that can be received on the receiving
window, range: 4-10
< times> The maximum number of retransmission retries of tunnel control packets,
range: 1-10
< time> The retransmission time-out time of tunnel control packets, range: 1-8
seconds
< time> The time for how long to wait for a response when a tunnel is started to be
established, range: 5-60 seconds
< time> The time-out time of deleting a tunnel when there is no session on the
tunnel, range: 1-65535 seconds
< local-name> The local name of the tunnel, 1-31 characters
< ip-address> The source address or the peer-end address of a tunnel
< priority> The priority of the peer-end address of a tunnel, range: 0-65535. The
smaller value, the higher priority.
< template-no> The serial number of a virtual template, range: 1-64
< num> The maximum number of L2TP sessions that are allowed in a VPDN group
or a tunnel, range: 1-16000
< domain-name> Domain name, 1-31 characters
< hostname> The local name of the peer-end of the tunnel, 1-31 characters
5-10

5.4 L2TP Maintenance

ZXR10 M6000 provides the following commands to maintain L2TP.
Command Function
ZXR10#show vpdn failure This shows the failure reason.
ZXR10#show vpdn group [ < group-name> ] This shows configuration information of

a VPDN group.
ZXR10#show vpdn tunnel { brief | local-tunnel-id < tunnel-id> [ This shows information of a tunnel.
local-session < session-id> ] | remote-name < remote-name> }
ZXR10#show vpdn session [ local-tunnel-id < tunnel-id> [ local-session < This shows information of a session.
session-id> ]
ZXR10#show debug l2tp This shows the debugging functions

that have been enabled in L2TP.
ZXR10#debug l2tp { all | data | error | event | packet} This shows L2TP debugging
information.
An example of the show vpdn failure command output is shown below.

ZXR10#show vpdn failure
L2TP failure cach size :20 failure :2
Local tunnel ID: 32538 Local session ID: 2
Peer tunnel ID : 46112 Peer session ID : 4
session ident : LNS
session prestate : Est
session curstate : Idle
Local IP address = 1.1.1.8
Peer IP address = 1.1.1.6
Session close flag: Close from local!
Session offline reason: Sevice reboot!
time: 2011-1-11 10:37:28 867ms
---------------------------------------
Local tunnel ID: 43227 Local session ID: 1
Peer tunnel ID : 44773 Peer session ID : 3
session ident : LNS
session prestate : Est
session curstate : Idle
Local IP address = 1.1.1.8
Peer IP address = 1.1.1.6
Session close flag: Close from local!
Session offline reason: Sevice reboot!
time: 2011-1-11 10:36:30 227ms
---------------------------------------
5-11

Est Established state
Idle Idle state
An example of the show vpdn group command output is shown below.

ZXR10#show vpdn group
vpdn-group:zte1
service-type:LNS
proxy-authentication:Yes
new-random:No
domain:
force-local-chap:No
lcp renegotiation:lcp renegotiation always
lns-send-sli:No
terminate-from hostname:LAC
virtual-template:1
vrf:
l2tp hidden:No
l2tp sequencing:No
l2tp tunnel authentication:No
l2tp tunnel password:cisco
l2tp tunnel hello:60s
l2tp tunnel receive-window:4
l2tp tunnel retransmit retries:5
l2tp tunnel retransmit timeout:8s
l2tp tunnel timeout setup:10s
l2tp tunnel timeout no-session:15s
local name:LNS
max-session:16000
max-session-per-tunnel:16000
source-ip-addr:0.0.0.0
initiate-to-ip-addr[0] ip:0.0.0.0 priority:0
current total user number:0
An example of the show vpdn tunnel brief command output is shown below.
ZXR10#show vpdn tunnel brief
L2TP Tunnel Infomation [Total tunnels :1] [Total sessions :1]
5-12

LTID RTID RemoteName State RemoteAddr RemotePort Sessions

43227 44773 LAC EST 1.1.1.6 1701 1
ZXR10#show vpdn tunnel local-tunnel-id 51367
---------------------------------------------------------------
LocTID : 51367 RemTID : 46332
State : EST OnlineTime : 41(s)
LocName : 103 RemName : 88
LocAddr : 192.1.1.2 RemAddr : 192.1.1.1
LocPort : 1701 RemPort : 1701
NowSessions : 1 FailSessions : 0
RcvCtrlPacket: 2 SendCtrlPacket: 4
RcvZLB : 2 SendZLB : 0
SendSeqAck : 3 RcvSeqAck : 1
RcvOutSeq : 0 RcvOutWin : 0
PeerRcvWnd : 4 SendWndSize : 4
WinNss : 4 WinUna : 4
WinNr : 2 AckTimeOut : 0
RxHello : 0 TxZLBForHello : 0
------------------------------------------------------------
ZXR10#show vpdn tunnel remote-name 88
------------------------------------------------------------
LocTID : 51367 RemTID : 46332
State : EST OnlineTime : 65(s)
LocName : 103 RemName : 88
LocAddr : 192.1.1.2 RemAddr : 192.1.1.1
LocPort : 1701 RemPort : 1701
NowSessions : 1 FailSessions : 0
RcvCtrlPacket: 3 SendCtrlPacket: 4
RcvZLB : 2 SendZLB : 1
SendSeqAck : 3 RcvSeqAck : 2
RcvOutSeq : 0 RcvOutWin : 0
PeerRcvWnd : 4 SendWndSize : 4
WinNss : 4 WinUna : 4
WinNr : 3 AckTimeOut : 0
RxHello : 1 TxZLBForHello : 1
---------------------------------------------------------------
EST Established state
An example of the show vpdn session command output is shown below.

ZXR10#show vpdn session
LocSID: 3 RemSID : 1
5-13

LocTID: 51367 RemTID : 46332

State : Est OnlineTime: 25(s)
Ident : LAC SesIntface: gei-0/0/0/2
Est Established state
LAC The service type is LAC.
An example of the show vpdn debug command output is shown below.

ZXR10#show vpdn debug
L2TP:
L2TP error debugging is on
L2TP event debugging is on
L2TP data debugging is on
L2TP packet debugging is on
5.5 L2TP Configuration Examples

5.5.1 Configuring an LNS
As shown in Figure 5-8, ZXR10 M6000 works as an LNS. It establishes a tunnel with the
LAC. Users access the private enterprise network through the tunnel.
Figure 5-8 LNS Configuration Example
1. Configure an address pool that allocates addresses to users.
2. Create a virtual template in global configuration mode and enter virtual template
configuration mode. Set the mode to PPP and bind the template to an interface.
3. Enter user configuration mode. Configure a domain name, a username and a
password. The domain name is L2TP, the username is lac1, and the password is 123.
4. Enter virtual template configuration mode from PPP configuration mode. Set the user
authentication mode to PAP. Configure a username and a password. Bind the address
pool.
5. Configure an IP address on the interface connected to the LAC.
5-14

6. In global configuration, enter VPDN configuration mode. Configure a VPDN group.

Configure the service type, the source IP address, the destination address, the local
name and the peer-end name of the tunnel. Bind a virtual interface and disable tunnel
authentication.
The configuration of LNS:
R2(config)#ip pool zte
R2(config-ip-pool)#range 135.1.0.1 135.1.255.254 255.255.0.0
R2(config-ip-pool)#exit
R2(config)#interface gei-0/2/0/2
R2(config-if)#exit
R2(config)#interface virtual_template20
R2(config-if)#mode ppp
R2(config-if)#ip unnumbered gei-0/2/0/2
R2(config-if)#exit
R2(config)#ppp
R2(config-ppp)#interface virtual_template20
R2(config-ppp-if)#keepalive 20
R2(config-ppp-if)#ppp authentication pap
R2(config-ppp-if)#bind-ip-pool zte
R2(config-ppp-if)#exit
R2(config-ppp)#exit
R2(config)#system-user
R2(config-system-user)#user-group special l2tp lac1 123
R2(config-system-user)#exit
R2(config)#vpdn-group zte
R2(config-vpdn-group)#service-type lns
R2(config-vpdn-group)#local name ztelns
R2(config-vpdn-group)#terminate-from hostname ztelac
R2(config-vpdn-group)#virtual-template 20
R2(config-vpdn-group)#exit
Use the show ip interface command to view the virtual access interfaces of online users.
R2(config)#show ip interface brief
gei-0/2/0/1 unassigned unassigned down down down
gei-0/2/0/2 102.1.1.1 255.255.255.0 up up up
5-15


gei-0/2/0/10unassigned unassigned down down down
virtual_template20 102.1.1.1 255.255.255.0 up up down
virtual_access1127 102.1.1.1 255.255.255.0 up up up
A virtual access interface is generated when one user is online.

Use the show running-config ppp all command to view the PPP configuration.
R1(config)show running-config ppp

! <PPP>
ppp
interface virtual_template20
keepalive 20
ppp authentication PAP
bind-ip-pool zte
bind-authen-template 1
!
! </PPP>
Use the show ip local pool command to view the address pool configuration.
R2(config)#show ip local pool
PoolName Begin End Mask Bind
b 40.40.1.2 40.40.10.254 16 PPP
20 202.119.22.10 202.119.22.255 16 DHCP
Use the show logicinterface summary command to view summary information of the virtual
access interfaces.
R2(config)#show logicinterface summary
ACCESS NA NA NA 3
5.5.2 Configuring an LTS

As shown in Figure 5-9, ZXR10 M6000 works as an LTS. It is necessary to configure
the for the L2TP group of the LAC and the L2TP group of the LNS so that they provide
LTS characteristics. The configuration of the LTS domain is the same as that of the LAC
domain. It is necessary to specify the L2TP groups, but it is unnecessary to specify address
pools.
5-16

Figure 5-9 LTS Configuration Example
1. The basic characteristics of an LTS are: On the one hand, an LTS works as an LNS to
respond the tunnel connection request of the LAC at the user side. On the other hand,
the LTS works as an LAC to send a tunnel connection request to the LNS (or another
LTS) at the server side. Therefore, to configure an LTS, it is necessary to create two
L2TP groups. One group works as an LNS to receive the tunnel connection request
sent by the LAC. The other group works as an LAC to send the tunnel connection
request to the LNS.
2. Configure addresses on the interfaces connected to the LAC and the LNS.
3. Create a virtual template in global configuration mode and enter virtual template
configuration mode. Set the mode to PPP and bind the template to an interface.
4. Configure domains of the L2TP users.
5. Configure an LAC. For details, please refer to LAC configuration.
6. Configure an LNS. For details, please refer to LNS configuration.
The configuration of LTS:
R2(config-if)#no shutdown
R2(config-if)#exit
R2(config-if)#no shutdown
R2(config-if)#exit
R2(config)#interface virtual_template20
R2(config-if)#mode ppp
R2(config-if)#ip unnumbered gei-0/2/0/2
R2(config-if)#exit
R2(config)#ppp
R2(config-ppp)#interface virtual_template20
R2(config-ppp-if)#keepalive 20
R2(config-ppp-if)#ppp authentication pap
R2(config-ppp-if)#ppp pap sent-username bras@zte password 123
R2(config-ppp-if)#bind-ip-pool zte
R2(config-ppp-if)#exit
R2(config-ppp)#exit
5-17

R2(config)#vpdn
R2(config-vpdn)#enable
R2(config-vpdn)#multihop
R2(config-vpdn)#tsa-id lts
R2(config-vpdn)#exit
R2(config)#vpdn-group lns
R2(config-vpdn-group)#service-type lns
R2(config-vpdn-group)#local name lns
R2(config-vpdn-group)#terminate-from hostname lac
R2(config-vpdn-group)#virtual-template 20
R2(config-vpdn-group)#l2tp tunnel authentication
R2(config-vpdn-group)#l2tp tunnel password zte
R2(config)#vpdn-group lac
R2(config-vpdn-group)#domain zte
R2(config-vpdn-group)#local name lac
R2(config-vpdn-group)#terminate-from hostname lns
R2(config-vpdn-group)#proxy-authentication
R2(config-vpdn-group)#source-ip-addr 102.1.1.2
R2(config-vpdn-group)#initiate-to-ip-addr 102.1.1.1
Use the show vpdn tunnel command to check the tunnel state. The tunnel has been
established. When a user is online, the system generates two tunnels automatically. One
tunnel is between the LAC and the LTS. The other tunnel is between the LTS and the LNS.
Use the show running-config ppp all command to view the PPP configuration.
R2(config)show running-config ppp

! <PPP>
ppp
interface virtual_template20
keepalive 20
ppp authentication PAP
ppp pap sent-username bras@zte password 123
bind-ip-pool zte
!
! </PPP>
5-18

5.6 L2TP Fault Handling

Take the topology shown in Figure 5-10 as an example to describe how to handle an LNS
fault.
Figure 5-10 Network Topology of an LNS Fault
Take the topology shown in Figure 5-11 as an example to describe how to handle an LTS
fault.
Figure 5-11 Network Topology of an LTS Fault

If an L2TP tunnel cannot be established, or users cannot get online, analyze the fault in
the hardware aspect and the software aspect.
l Check the Management Process Units (MPUs), the line cards, the interface cards
and the network cables (check whether the direct connected interfaces can be pinged
successfully from each other).
l If there is no problem about the hardware, check the configurations of the interfaces,
the VPDN groups and the address pool.
5.6.3 Handling Flow

The flow to handle an LNS fault is shown in Figure 5-12.
5-19

Figure 5-12 Flow to Handle an LNS Fault
The flow to handle an LTS fault is shown in Figure 5-13.
5-20

Figure 5-13 Flow to Handle an LTS Fault

Handling Procedure of an LNS Fault
The procedure to handle an LNS fault is described below.
1. Check whether there is a link fault or a port fault. If it is not, go to Step 3.
2. Check the physical links. Make sure that the physical links are working properly and
the IP addresses are correct.
3. Check whether the route to the LAN is reachable. If it is unreachable, configure the
routes between the LNS and the LAC. Check whether the VPDN group configuration
is the same as that on the LAC.
4. Check the interface configuration of the virtual template. Make sure that the mode is
set to PPP and an IP unnumbered address is configured.
5. Check the configuration of the virtual template in PPP mode. Make sure that the
authentication mode is configured, and an address pool is bound. Make sure that the
5-21

username and the password for authentication are configured in global configuration
mode.
6. Check the configuration of the address pool. Make sure that an invalid address pool
is configured and there are addresses in the address pool to allocate to the users.
Handling Procedure of an LTS Fault

The procedure to handle an LTS fault is described below.
1. Check whether there is a link fault or a port fault. If it is not, go to Step 3.
2. Check the physical links. Make sure that the physical links are working properly and
the IP addresses are correct.
3. Check whether the routes to the LAN/LNS are reachable. If the routes are
unreachable, configure the routes between the LTS and the LAC/LNS. Check whether
the VPDN group configuration is the same as that on the LAC/LNS.
4. Check the interface configuration of the virtual template. Make sure that the mode is
set to PPP and an IP unnumbered address is configured.
5. Check the configuration of the virtual template in PPP mode. Make sure that the
authentication mode is configured, and an address pool is bound. Make sure that the
username and the password for authentication are configured in global configuration
mode.
6. Check the configuration of the address pool. Make sure that an invalid address pool
is configured and there are addresses in the address pool to allocate to the users.
5-22

Chapter 6
GRE Configuration
Table of Contents
GRE Overview ...........................................................................................................6-1
GRE Principle.............................................................................................................6-2
Configuring GRE ........................................................................................................6-3
GRE Maintenance ......................................................................................................6-6
GRE Configuration Examples.....................................................................................6-8
GRE Fault Handling .................................................................................................6-12
6.1 GRE Overview

General Routing Encapsulation (GRE) is submitted to IETF by Cisco corporation and
Net-smiths corporation in 1994, numbered RFC 1701 and RFC 1702. At present, network
devices of many vendors support GRE tunnel protocol. A tunnel means that PDUs of a
protocol are encapsulated in PDUs of the same layer protocol or a higher layer protocol.
GRE is a widely used technology that encapsulates PDUs of a network layer protocol in
PDUs of any other network layer protocol. It is usually used to establish a GRE tunnel
to pass through different Layer 3 networks. GRE supports to encapsulate messages of a
protocol in messages of another protocol and transmit the messages on networks. It can
encapsulate the packets of some network layer protocols (such as IP and IPX), so that the
encapsulated packets can be transmitted through another network layer protocol (such as
IP).
In genenal case, system has a data packet which needs to be encapsulated and
transmitted to some destination. We calls this data packet as payload packet. Payload
packet is firstly encapsulated into a GRE data packet. The GRE data packet can be
encapsulated into another kind of protocol and then forwarded. The outer protocol is
named as delivery protocol. The format of a GRE data packet after encapsulation is
shown as Figure 6-1.
Figure 6-1 GRE Encapsulation
6-1

According to the type of payload packet before GRE encapsulation is IPv4 or IPv6, GRE
tunnel can be divided into GRE over IPv4 and GRE over IPv6. The source address and
destination address of the transmission protocol are got by GRE tunnel.
GRE tunnel can be established on host-host, host-device, device-host and device-device.
The terminal of tunnel is the final destination of message or the message needs to be
forwarded.
6.2 GRE Principle

6.2.1 GRE over IPv4 Tunnel
When a GRE tunnel is configured, the device searches for the tunnel index at the ingress of
the tunnel. When it finds the outer IP destination and source addresses, it encapsulates an
outer IP header and a GRE header to the source IP packet and then forwards the packets
through the tunnel. The device removes the outer IP header and the GRE header at the
egress and then forwards the common packet.
GRE over IPv4 Tunnel mainly includes tunnel encapsulation and de-encapsulation.
l Encapsulation principle: When IPv4 host or router is sending IPv4 flow, if message
outgoing interface is tunnel interface, verify tunnel type first. If it is GRE tunnel, do the
encapsulation of IPv4 header, of which IPv4 header source address and destination
address are got by user manual configuration. After encapsulation, the message will
be sent by the IPv4 message sending flow.
l De-encapsulation principle: It is the reversed process of encapsulation. Router
receives IPv4 data packet. If IPv4 header protocol number is 47, apply process
function of each protocol of IPv4 registration, enter into GRE de-encapsulation flow,
search for matched tunnel entry according to source address and destination address
of message. If it is found the IPv4 header and GRE header encapsulated by tunnel
are removed. The remaining IPv4 message is handled by IPv4 packet receiving flow.
6.2.2 GRE over IPv6 Tunnel

GRE over IPv4 Tunnel mainly includes tunnel encapsulation and de-encapsulation.
l Encapsulation principle: When IPv6 host or router is sending IPv6 flow, if message
outgoing interface is tunnel interface, verify tunnel type first. If it is GRE tunnel, do the
encapsulation of IPv4 header, of which IPv4 header source address and destination
address are got by user manual configuration. After encapsulation, the message will
be sent by the IPv4 message sending flow.
l De-encapsulation principle: It is the reversed process of encapsulation. Router
receives IPv4 data packet. If IPv4 header protocol number is 47, apply process
function of each protocol of IPv4 registration, enter into GRE de-encapsulation flow,
search for matched tunnel entry according to source address and destination address
of message. If it is found the IPv4 header and GRE header encapsulated by tunnel
are removed. The remaining IPv6 message is handled by IPv6 packet receiving flow.
6-2

Chapter 6 GRE Configuration
6.3 Configuring GRE

6.3.1 Configuring GRE Over IPv4 Tunnel
To configure GRE over IPv4 tunnel on ZXR10 M6000, perform the following steps.
1 ZXR10(config)#interface gre_tunnel < tunnel no> This creates GRE tunnel interface.
Use the corresponding no command
to delete tunnel interface.
2 ZXR10(config)#gre-config This enters into GRE tunnel

configuration mode.
3 ZXR10(config-gre)#interface gre_tunnel < tunnel no> This enters into GRE tunnel interface
configuration mode.
4 ZXR10(config-gre-if)#tunnel mode ip This configures the current tunnel

mode as GRE over IPv4. Use
the corresponding no command to
delete the current mode.
5 ZXR10(config-gre-if)#tunnel source ipv4 < src addr> This configures tunnel source
address. Use the corresponding no
command to delete tunnel source
address configuration. Only IPv4
needs to be specified and the
detailed source address does not
need to be specified.
6 ZXR10(config-gre-if)#tunnel destination ipv4 < dst addr> This configures tunnel destination
address. Use the corresponding
no command to delete tunnel
destination address configuration.
Only IPv4 needs to be specified
and the detailed destination address
does not need to be specified.
7 ZXR10(config-gre-if)# tunnel key < key value> This configures tunnel key option.
to delete tunnel key option
configuration. Only key needs to be
specified and the detailed key value
8 ZXR10(config-gre-if)# tunnel sequence This enables tunnel serial number

function. Use the corresponding no
command to disable tunnel serial
number function configuration.
6-3

9 ZXR10(config-gre-if)# tunnel checksum This enables tunnel checksum

function. Use the corresponding
no command to disable tunnel
checksum function.
10 ZXR10(config-gre-if)# tunnel vrfname < vpn name> This configures across VRF instance
name after tunnel encapsulation.
to delete across VRF instance
configuration. Only vrfname needs
to be specified and the detailed
instance name does not need to be
specified.
Descriptions of the parameter in Step 1 and Step 3:
< tunnel no> Tunnel number, it means the nubmer of tunnel can be established is from 1
to 4000.
< src addr> It means the address of local interface used by tunnel.
< dst addr> It means the address of local interface used by tunnel.
< key value> It means key value used for tunnel security. The range of the key is
0–4294967295.
< vpn name> It means across VPN instance name after tunnel encapsulation.
6-4

6.3.2 Configuring GRE Over IPv6 Tunnel

To configure GRE over IPv6 tunnel on ZXR10 M6000, perform the following steps.
1 ZXR10(config)#interface gre_tunnel < tunnel no> This creates GRE tunnel interface.
to delete tunnel interface.
2 ZXR10(config)#gre-config This enters into GRE tunnel

configuration mode.
3 ZXR10(config-gre)#interface gre_tunnel < tunnel no> This enters into GRE tunnel interface
configuration mode.
4 ZXR10(config-gre-if)#tunnel mode ipv6 This configures the current tunnel

mode as GRE over IPv6. Use
the corresponding no command to
delete the current mode.
5 ZXR10(config-gre-if)#tunnel source ipv4 < src addr> This configures tunnel source
address. Use the corresponding no
command to delete tunnel source
address configuration. Only IPv4
needs to be specified and the
detailed source address does not
need to be specified.
6 ZXR10(config-gre-if)#tunnel destination ipv4 < dst addr> This configures tunnel destination
address. Use the corresponding
no command to delete tunnel
destination address configuration.
Only IPv4 needs to be specified
and the detailed destination address
7 ZXR10(config-gre-if)# tunnel key < key value> This configures tunnel key option.
to delete tunnel key option
configuration. Only key needs to be
specified and the detailed key value
8 ZXR10(config-gre-if)# tunnel sequence This enables tunnel serial number

function. Use the corresponding no
command to disable tunnel serial
number function configuration.
6-5

9 ZXR10(config-gre-if)# tunnel checksum This enables tunnel checksum

function. Use the corresponding
no command to disable tunnel
checksum function.
Descriptions of the parameter in Step 1 and Step 3:
< tunnel no> Tunnel number, it means the number of tunnel can be established is from 1
to 4000.
< src addr> It means the address of local interface used by tunnel.
< dst addr> It means the address of destination interface used by tunnel.
< key value> It means key value used for tunnel security.
6.4 GRE Maintenance

ZXR10 M6000 provides the following commands to maintain GRE.
Command Function
ZXR10#debug gre-tunnel This enables GRE tunnel debug

switch and views encapsulation and
de-encapsulation information.
ZXR10#show debug gre-tun This checks if GRE tunnel debug switch

is enabled.
An example of the debug v6-tunnel command output is shown below.

ZXR10# debug gre-tunnel
GRE-tunnel debugging has been turned on
6-6

ZXR10# terminal monitor

0/1/CPU0 2010-4-7 15:48:31 gre_tunnel1: GRE/IPv4 to be decapsulated
100.100.1.2->100.100.1.1 (len=124 ttl=255)
0/1/CPU0 2010-4-7 15:48:31 gre_tunnel1: GRE decapsulated 1234::2->
1234::1 (len=100 ttl=64)
0/20/CPU0 2010-4-7 15:48:31 gre_tunnel1: GRE/IPv6 to be encapsulated
1234::1->1234::2 (len=100 ttl=64)
0/20/CPU0 2010-4-7 15:48:31 gre_tunnel1: GRE encapsulated IPv4
100.100.1.1->100.100.1.2 (len=136 ttl=255)
gre_tunnel1 GRE tunnel interface
GRE/IPv4 At present, the message protocol that GRE tunnel is processing is IPv4.
If it is IPv6 GRE/IPv6 is displayed.
be encapsulated Before encapsulation
encapsulated After encapsulation
len Packet length
ttl lifecycle
be decapsulated Before de-encapsulation
decapsulated After de-encapsulation
An example of the show debug gre-tun command output is shown below.

ZXR10#debug gre-tunnel
GRE-tunnel debugging has been turned on
ZXR10#show debug gre-tun
GRE-TUNNEL:
GRE-tunnel packets debugging is on
ZXR10#no debug gre-tunnel
GRE-tunnel debugging is off
ZXR10#show debug gre-tun
6-7

6.5 GRE Configuration Examples

6.5.1 Basic GRE Configuration Example
As shown in Figure 6-2, GRE tunnel is configured between R1 and R2. R1 interface
address is 100.0.0.1/24, GRE interface address is 11.0.0.1/24. R2 interface address is
200.0.0.1/24, GRE interface address is 11.0.0.2/24.
Figure 6-2 Basic GRE Configuration Example
1. Configure the interface IP addresses on R1 and R2, create route to make the two
routers interconnected.
2. Create gre_tunnel interface on global mode and allocate the corresponding IP address.
3. Enter into GRE configuration mode at global configuration mode and enter into the
GRE interface to be configured.
4. Configure GRE on R1 and R2 respectively. Set GRE working mode and bound source
and destination interface addresses.
R1(config-if)#ip adderss 100.0.0.1 255.255.255.0
R1(config-if)exit
R1(config)#interface gre_tunnel1
R1(config-if)#exit
R1(config)#gre-config
R1(config-gre)#interface gre_tunnel1
R1(config-gre-if)#tunnel mode ip
6-8

R1(config-gre-if)#tunnel source ipv4 100.0.0.1

R1(config-gre-if)#tunnel destination ipv4 200.0.0.1
R1(config-gre-if)#
R2(config-if)exit
R2(config-if)#exit
R2(config-gre-if)#tunnel mode ip
R2(config-gre-if)#
Check the GRE configuration on R1 and R2, as shown below.
R1(config)#show running-config gre-tunnel1
! <GRE>
gre-config
interface gre_tunnel1
tunnel mode ip
tunnel source ipv4 100.0.0.1
tunnel destination ipv4 200.0.0.1
! </GRE>
! <INTERFACE>
index 17
ip address 11.0.0.1 255.255.255.0
! </INTERFACE>
!
R1(config)#show ip interface gre_tunnel1
gre_tunnel1 AdminStatus is up, PhyStatus is up, line protocol is up
Internet address is 11.0.0.1/24 /*all are up, tunnel is valid.*/
Broadcast address is 255.255.255.255
IP MTU is 1476 bytes
R2(config)#show running-config-interface gre_tunnel1

! <GRE>
gre-config
6-9

tunnel mode ip
!</GRE>
!<INTERFACE>
index 11
ip address 11.0.0.2 255.255.255.0
!</INTERFACE>
!
R2(config)#show ip interface gre_tunnel1
gre_tunnel1 AdminStatus is up, PhyStatus is up, line protocol is up
Internet address is 11.0.0.2/24 /*all are up, tunnel is valid.*/
Broadcast address is 255.255.255.255
IP MTU is 1476 bytes
6.5.2 GRE 6in4 Configuration Example

As shown in Figure 6-3, GRE tunnel is configured between R1 and R2. R1 interface
address is 100.0.0.1/24, GRE interface address is 2010::11/64. R2 interface address is
200.0.0.1/24, GRE interface address is 2010::22/64.
Figure 6-3 GRE 6in4 Configuration Example
1. Configure the interface IP addresses on R1 and R2, create route to make the two
routers interconnected.
2. Create gre_tunnel interface on global mode and allocate the corresponding IPv6
address.
3. Enter into GRE configuration mode at global configuration mode and enter into the
GRE interface to be configured.
6-10

4. Configure GRE on R1 and R2 respectively. Set GRE working mode and bound source
and destination interface addresses.
R1(config-if)#ip adderss 100.0.0.1 255.255.255.0
R1(config-if)exit
R1(config-if)#ipv6 address 2010::11/64
R1(config-if)#exit
R1(config-gre-if)#tunnel mode ipv6
R1(config-gre-if)#tunnel key 1
R2(config-if)exit
R2(config-if)#ipv6 address 2010::22/64
R2(config-if)#exit
R2(config-gre-if)#tunnel mode ipv6
R2(config-gre-if)#tunnel key 1
Check the GRE configuration on R1 and R2, as shown below.
R1(config)#show running-config-interface gre-tun gre_tunnel1
! <GRE>
gre-config
tunnel mode ipv6
tunnel key 1
! </GRE>
! <INTERFACE>
6-11

index 17
ipv6 enable
ipv6 address 2010::11/64
! </INTERFACE>
R1(config)#show ipv6 interface gre_tunnel1

Interface gre_tunnel1
IPv6 is enable, Hardware is Gre Tunnel
index 17
inet6 fe80::2dd:d0ff:fe33:3292/64
inet6 2010::11/64 /*if invalid, there is [tentative]*/
R2(config)#show running-config-interface gre-tun gre_tunnel1

! <GRE>
gre-config
tunnel mode ipv6
tunnel key 1
! <GRE>
!<INTERFACE>
index 11
ipv6 enable
ipv6 address 2010::22/64
! </INTERFACE>
R2(config)#show ipv6 interface gre_tunnel1

Interface gre_tunnel1
IPv6 is enable, Hardware is Gre Tunnel
index 17
inet6 fe80::2dd:d0ff:fe33:3292/64
inet6 2010::22/64 /*if invalid, there is [tentative]*/
6.6 GRE Fault Handling

In practical applications, the main faults of GRE are that tunnel interface cannot
communicate with each other. Take the topology shown in Figure 6-4 as an example to
describe how to handle a GRE fault.
6-12

Figure 6-4 Network Topology of a GRE Fault

The main reason that GRE interface cannot communicate can be analyzed from two points:
hardware and software. For hardware aspect, check main board, line card, interface board
and cable(see if the direct-connecting interfaces of both ends can be pinged through).
If the hardware is without any problem check software including GRE configuration, if
the configurations of both ends are consistent, the binding real interface address can be
reached.
6.6.3 Handling Flow

The flow to handle a GRE fault is shown in Figure 6-5.
6-13

Figure 6-5 Flow to Handle a GRE Fault

The procedure to handle a GRE fault is described below.
1. Make sure that fibers or network cables have no fault, and there is no exception on
interface boards.
2. Check whether the IP addresses and masks configured on the GRE interfaces at both
ends are reachable.
3. Check whether GRE interfaces are in UP state by using the show ip interface brief
command and ensure that interface running state is normal.
4. Check whether GRE uses the same mode (IPv4 or IPv6).
5. Check whether the GRE source and destination correspond each other. The local
source address should be the destination address of the peer, vice versa.
6. If key of GRE option is configured, the same key value should be used.
6-14

6-15

6-16

Figures
Figure 2-1 VPWS Working Principle.......................................................................... 2-2
Figure 2-2 VPLS Working Principle ........................................................................... 2-3
Figure 2-3 VPLS Working Principle ........................................................................... 2-4
Figure 2-4 Network Structure of L2VPN VPLS Un-Qualified Configuration .............. 2-17
Figure 2-5 Network Topology of a VPLS Fault......................................................... 2-24
Figure 2-6 Flow to Handle a VPLS Fault ................................................................ 2-26
Figure 2-7 VPLS-MAC Filter Configuration Example ............................................... 2-30
Figure 2-8 Network Topology of a VPLS-MAC Filtering Fault .................................. 2-33
Figure 2-9 Flow to Handle a VPLS-MAC Filtering Fault........................................... 2-34
Figure 2-10 VPLS Heterogeneouse Function Configuration Example...................... 2-36
Figure 2-11 Network Topology of a VPLS Heterogeneous Function Fault................ 2-38
Figure 2-12 Flow to Handle a VPLS Heterogeneous Function Fault ........................ 2-40
Figure 2-13 Network Structure of L2VPN VPWS Ethernet PW Configuration ........... 2-49
Figure 2-14 Network Structure of L2VPN VPWS IP Heterogeneous PW
Configuration ........................................................................................ 2-52
Figure 2-15 Network Topology of a VPWS Fault ..................................................... 2-55
Figure 2-16 Flow to Handle a VPWS Fault.............................................................. 2-56
Figure 2-17 VPWS Heterogeneous Function Configuration Example ...................... 2-59
Figure 2-18 Network Topology of a VPWS Heterogeneouse Function Fault ............ 2-62
Figure 2-19 Flow to Handle a VPWS Heterogeneouse Function Fault..................... 2-63
Figure 2-20 L2 VPN and L3 VPN Bridge Configuration Example............................. 2-65
Figure 2-21 Network Topology of an L2 VPN and L3 VPN Bridge Fault................... 2-67
Figure 2-22 Flow to Handle an L2 VPN and L3 VPN Bridge Fault ........................... 2-68
Figure 2-23 VPLS FRR Configuration Example....................................................... 2-71
Figure 2-24 Network Topology of a L2 VPN FRR Fault............................................ 2-73
Figure 2-25 Flow to Handle a L2 VPN FRR Fault .................................................... 2-74
Figure 2-26 Network Topology of MAC Ping and MAC Trace ................................. 2-75
Figure 2-27 MAC PING and MAC PING TRACE Configuration Example ................ 2-78
Figure 2-28 Network Topology of a MAC Ping/MAC Trace Fault ............................. 2-80
Figure 2-29 Flow to Handle a MAC Ping/MAC Trace Fault...................................... 2-81
Figure 2-30 Typical Network Structure of Connecting Two CEs to Two PEs ............ 2-82
Figure 2-31 Connecting Two CEs to Two PEs in PWE3 Application ....................... 2-83
I
Figure 2-32 MC-ELAM Configuration Example........................................................ 2-89

Figure 2-33 Network Topology of an MC-ELAM Fault.............................................. 2-91
Figure 2-34 Flow to Handle an MC-ELAM Fault ...................................................... 2-92
Figure 3-1 Running Static Route Protocol between CE and PE................................. 3-7
Figure 3-2 Running RIP between CE and PE............................................................ 3-8
Figure 3-3 Running OSPF between CE and PE ...................................................... 3-10
Figure 3-4 Running EBGP between CE and PE...................................................... 3-11
Figure 3-5 MPBGP Protocol Configuration.............................................................. 3-12
Figure 3-6 RR Configuration Example Topology...................................................... 3-14
Figure 3-7 MPLS L3VPN Basic Configuration Example Topology............................ 3-18
Figure 3-8 MPLS VPN OSPF SHAM-LINK Configuration Example Topology ........... 3-23
Figure 3-9 MPLS VPN Cross-Domain Configuration Example................................. 3-28
Figure 3-10 Network Topology of an MPLS VPN Fault ............................................ 3-31
Figure 3-11 Flow to Handle an MPLS VPN Fault.................................................... 3-34
Figure 3-12 MPLS VPN Route Aggregation Configuration Example
Topology ............................................................................................... 3-39
Figure 3-13 Network Topology of an MPLS VPN Route Aggregation Fault .............. 3-43
Figure 3-14 Flow to Handle an MPLS VPN Route Aggregation Fault ...................... 3-44
Figure 3-15 VPN Route Alarm Configuration Example ............................................ 3-49
Figure 3-16 Network Topology of an MPLS VPN Route Aggregation Fault .............. 3-52
Figure 3-17 Flow to Handle a VPN Route Restriction and Alarm Fault .................... 3-53
Figure 3-18 L3 VPN FRR Network Structure ........................................................... 3-55
Figure 3-19 L3 VPN FRR Configuration Example.................................................... 3-56
Figure 3-20 Network Topology of an L3 VPN FRR Fault.......................................... 3-61
Figure 3-21 Flow to Handle an L3 VPN FRR Fault .................................................. 3-62
Figure 3-22 LDP Load Balancing Principle.............................................................. 3-63
Figure 3-23 MPLS Load Balancing Configuration Example ..................................... 3-65
Figure 3-24 Network Topology of an LDP Load Balancing Fault .............................. 3-68
Figure 3-25 Flow to Handle an LDP Load Balancing Fault ...................................... 3-69
Figure 3-26 VRF Load Balancing Configuration Example........................................ 3-73
Figure 3-27 Network Topology of a VRF Load Balancing Fault................................ 3-75
Figure 3-28 Flow to Handle a VRF Load Balancing Fault ........................................ 3-76
Figure 4-1 Multicast VPN Configuration Example...................................................... 4-9
Figure 4-2 Network Topology of a VPN Multicast Fault............................................ 4-16
Figure 4-3 Flow to Handle a VPN Multicast Fault .................................................... 4-17
Figure 5-1 Three L2TP Access Modes...................................................................... 5-3
II
Figures
Figure 5-2 L2TP Encapsulation................................................................................. 5-4

Figure 5-3 L2TP Tunnel and Session Establishment Flow......................................... 5-5
Figure 5-4 L2TP Tunnel Maintenance ....................................................................... 5-6
Figure 5-5 L2TP Tunnel and Session Backout Flow .................................................. 5-6
Figure 5-6 Typical LTS .............................................................................................. 5-7
Figure 5-7 Typical L2TP LTS Application Network Structure...................................... 5-7
Figure 5-8 LNS Configuration Example ................................................................... 5-14
Figure 5-9 LTS Configuration Example.................................................................... 5-17
Figure 5-10 Network Topology of an LNS Fault ....................................................... 5-19
Figure 5-11 Network Topology of an LTS Fault ........................................................ 5-19
Figure 5-12 Flow to Handle an LNS Fault ............................................................... 5-20
Figure 5-13 Flow to Handle an LTS Fault ................................................................ 5-21
Figure 6-1 GRE Encapsulation.................................................................................. 6-1
Figure 6-2 Basic GRE Configuration Example........................................................... 6-8
Figure 6-3 GRE 6in4 Configuration Example........................................................... 6-10
Figure 6-4 Network Topology of a GRE Fault .......................................................... 6-13
Figure 6-5 Flow to Handle a GRE Fault .................................................................. 6-14
III
Figures

Tables
Table 3-1 MPLS VPN Basic Configuration Address Table ...................................... 3-18
Table 3-2 MPLS VPN OSPF SHAM-LINK Address Table ........................................ 3-23
Table 3-3 MPLS VPN Interface Address Table ........................................................ 3-39
V
Tables

Glossary
AAA
- Authentication, Authorization and Accounting
AC
- Access Circuit
ARP
- Address Resolution Protocol
AS
- Autonomous System
ATM
- Asynchronous Transfer Mode
BFD
- Bidirectional Forwarding Detection
BGP
- Border Gateway Protocol
BPDU
- Bridge Protocol Data Unit
BSC
- Base Station Controller
BSR
- Bootstrap Router
BTS
- Base Transceiver Station
CC
- Connection Confirmation
CE
- Customer Edge
CIP
- Customer Interface Point
EBGP
- External Border Gateway Protocol
FEC
- Forwarding Equivalence Class
FR
- Frame Relay
VII
FRR
- Fast Reroute
GRE
- General Routing Encapsulation
HDLC
- High-level Data Link Control
IANA
- Internet Assigned Number Authority
IBGP
- Interior Border Gateway Protocol
IEEE
- Institute of Electrical and Electronics Engineers
IETF
- Internet Engineering Task Force
IGMP
- Internet Group Management Protocol
IGP
- Interior Gateway Protocol
ILMI
- Interim Local Management Interface
IP
- Internet Protocol
IPCP
- IP Control Protocol
IPSec
- IP Security Protocol
IS-IS
- Intermediate System-to-Intermediate System
ISDN
- Integrated Services Digital Network
ISP
- Internet Service Provider
L2TP
- Layer2 Tunneling Protocol
LAC
- L2TP Access Concentrator
LAN
- Local Area Network
VIII
Glossary
LDP
- Label Distribution Protocol
LMI
- Local Management Interface
LNS
- L2TP Network Server
LSP
- Label Switched Path
LSP
- Link State Packet
LSR
- Label Switch Router
MAC
- Medium Access Control
MAN
- Metropolitan Area Network
MC-ELAM
- Multi-Chassis Ethernet Link Aggregation Manager
MP-BGP
- Multiprotocol BGP
MPLS
- Multi Protocol Label Switching
MPU
- Management Process Unit
MTU
- Maximum Transmission Unit
NAS
- Network Access Server
NAT
- Network Address Translation
OAM
- Operation, Administration and Maintenance
OSPF
- Open Shortest Path First
PDU
- Protocol Data Unit
PE
- Provider Edge
IX
PIM-SM
- Protocol Independent Multicast - Sparse Mode
POS
- Packet Over SONET/SDH
PPP
- Point to Point Protocol
PPTP
- PPP Tunnel Protocol
PSTN
- Public Switched Telephone Network
PW
- Pseudo Wire
PWE3
- Pseudo Wire Emulation Edge-to-Edge
RAN
- Radio Access Network
RD
- Route Distinguisher
RFC
- Request For Comments
RIP
- Routing Information Protocol
RP
- Rendezvous Point
RPF
- Reverse Path Forwarding
RR
- Router Reflector
RSVP-TE
- Resource ReSerVation Protocol - Traffic Engineering
RT
- Route Target
SDH
- Synchronous Digital Hierarchy
SDU
- Service Data Unit
SP
- Service Provider
X
Glossary
STP
- Spanning Tree Protocol
TCP/IP
- Transfer Control Protocol/Internet Protocol
TDM
- Time Division Multiplexing
TTL
- Time To Live
UDP
- User Datagram Protocol
VC
- Virtual Connection
VC
- Virtual Circuit
VCC
- Virtual Channel Connection
VCCV
- Virtual Circuit Connectivity Verification
VFI
- Virtual Forwarding Instance
VLAN
- Virtual Local Area Network
VPLS
- Virtual Private LAN Service
VPN
- Virtual Private Network
VPWS
- Virtual Private Wire Service
VRF
- Virtual Route Forwarding
WAN
- Wide Area Network
XI

ZXR10 M6000 (V1.00.30) Carrier-Class Router Configuration Guide (VPN) PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ZXR10 M6000 (V1.00.30) Carrier-Class Router Configuration Guide (VPN) PDF

Hochgeladen von

Copyright:

Verfügbare Formate

ZXR10 M6000

Revision No. Revision Date Revision Reason

R2.1 2011-05-10 Third release

The follwoing chapters are added.

The follwoing chapters are modified.

l MPLS L2 VPN Configuration

R2.0 2011-01-15 Second release, the document architecture is changed.

R1.0 2010-09-30 First release

Serial Number: SJ-20110504161056-016

Publishing Date: 2010-05-10 (R2.1)

Chapter 2 MPLS L2 VPN Configuration.................................................... 2-1

Chapter 3 MPLS L3 VPN Configuration.................................................... 3-1

Chapter 4 Multicast VPN Configuration ................................................... 4-1

Chapter 5 L2TP Configuration................................................................... 5-1

Chapter 6 GRE Configuration.................................................................... 6-1

What Is in This Manual

Chapter 5 L2TP Configuration Describes the L2TP principle, configuration commands,

Chapter 6 GRE Configuration Describes the GRE principle, configuration commands,

| Separates individual parameter in series of parameters.

Note: Provides additional information about a certain topic.

Checkpoint: Indicates that a particular step needs to be checked before proceeding

1.1 Safety Instruction

1.2 Safety Signs

SJ-20110504161056-016|2010-05-10 (R2.1) ZTE Proprietary and Confidential

SJ-20110504161056-016|2010-05-10 (R2.1) ZTE Proprietary and Confidential

2.1 MPLS L2 VPN Overview

SJ-20110504161056-016|2010-05-10 (R2.1) ZTE Proprietary and Confidential

l Virtual Private LAN Service (VPLS)

2.1.2 MPLS L2 VPN Principle

Figure 2-1 VPWS Working Principle

VPWS working mode: point-to-point.

VPLS: VPLS is to provide Ethernet emulation services on MPLS network. It connects

SJ-20110504161056-016|2010-05-10 (R2.1) ZTE Proprietary and Confidential

Figure 2-2 VPLS Working Principle

VPLS: An ISP provides multipoint-to-multipoint L2 connections in a metropolitan area or

2.2 VPLS Basic Function Configuration

VPLS working principle is shown in Figure 2-3.

SJ-20110504161056-016|2010-05-10 (R2.1) ZTE Proprietary and Confidential

Figure 2-3 VPLS Working Principle

VPLS working flow is described below.

SJ-20110504161056-016|2010-05-10 (R2.1) ZTE Proprietary and Confidential

2.2.2 Configuring VPLS

Step Command Function

1 ZXR10(config)#vpls < vpls-name> This creates a VPLS instance.

2 ZXR10(config)#sdu < 1-55968> This creates a Service Data

3 ZXR10(config)#pw-redundancy-manager pw_redundancy < This configures a PW redundancy

SJ-20110504161056-016|2010-05-10 (R2.1) ZTE Proprietary and Confidential

Step Command Function

4 ZXR10(config-vpls)#sac < ac-interface> [ client] This specifies an interface to be

ZXR10(config-vpls)#sdu < sdu-number> This binds an SDU to the current

ZXR10(config-vpls)#spoke-sdu < sdu-number> This binds an SDU to the current

ZXR10(config-vpls)#default-vcid < vcid> This configures the default VCID of

ZXR10(config-vpls)#mac This enters mpls mac configuration

ZXR10(config-vpls)#mac-withdraw This enables mac-withdraw function.

ZXR10(config-vpls)#mtu < mtu> This sets the Maximum Transmission

5 ZXR10(config-vpls-sac)#service-define ethernet This sets an AC to ethernet type.

6 ZXR10(config-vpls-sac-sd)#group-id < 1-63> This configures Clien-group-id.

ZXR10(config-vpls-sac-sd)#ingress-adjust { no-pop-outermost | This configures VLAN translation

8 ZXR10(config-vpls-sdu-pw)#control-word { used | unused } This sets a PW to use the control

ZXR10(config-vpls-sdu-pw)#vccv cc { pw-ach| ttl=1| alert-label} This sets a PW to support Virtual

SJ-20110504161056-016|2010-05-10 (R2.1) ZTE Proprietary and Confidential

Step Command Function

ZXR10(config-vpls-sdu-pw)#encapsulation { tagged | raw } This sets the encapsulation mode of