Troubleshooting HUAWEI VPN

HUAWEI NetEngine80E/40E Router
V600R003C00
Troubleshooting - VPN
Issue
02
Date
2011-09-10
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

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

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

Address:
Huawei Industrial Base

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

Copyright Huawei Technologies Co., Ltd.

About This Document
About This Document

Purpose
NOTE
l This document takes interface numbers and link types of the NE40E-X8 as an example. In working
situations, the actual interface numbers and link types may be different from those used in this
document.
l On NE80E/40E series excluding NE40E-X1 and NE40E-X2, line processing boards are called Line
Processing Units (LPUs) and switching fabric boards are called Switching Fabric Units (SFUs). On
the NE40E-X1 and NE40E-X2, there are no LPUs and SFUs, and NPUs implement the same functions
of LPUs and SFUs to exchange and forward packets.
This document describes how to troubleshoot the services of the HUAWEI NetEngine80E/
40E in terms of common faults and causes, troubleshooting cases, and FAQs.
This document describes the procedure and method for troubleshooting for the HUAWEI
NetEngine80E/40E.
Related Versions
The following table lists the product versions related to this document.
Product Name
Version
HUAWEI NetEngine80E/40E
Router
V600R003C00
Intended Audience
This document is intended for:
l
System maintenance engineers
Commissioning engineers
Network monitoring engineers
Issue 02 (2011-09-10)

ii

About This Document
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
DANGER
WARNING
CAUTION
Indicates a hazard with a high level of risk, which if not

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

time.
NOTE
Provides additional information to emphasize or supplement

important points of the main text.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Issue 02 (2011-09-10)
Convention
Description
Boldface
The keywords of a command line are in boldface.
Italic
Command arguments are in italics.
[]
Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... }
Optional items are grouped in braces and separated by

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

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

vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]*
Optional items are grouped in brackets and separated by

vertical bars. Several items or no item can be selected.
&<1-n>
The parameter before the & sign can be repeated 1 to n times.
A line starting with the # sign is comments.

iii

About This Document
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Changes in Issue 02 (2011-09-10)

The second commercial release. There is no update compared with the previous issue.
Changes in Issue 01 (2011-05-30)

Initial field trial release.
Issue 02 (2011-09-10)

iv

Contents
Contents
About This Document.....................................................................................................................ii
1 L3VPN Troubleshooting..............................................................................................................1
1.1 BGP Private Network Traffic Is Interrupted......................................................................................................2
1.1.1 Common Causes........................................................................................................................................2
1.1.2 Troubleshooting Flowchart........................................................................................................................2
1.1.3 Troubleshooting Procedure........................................................................................................................3
1.1.4 Relevant Alarms and Logs........................................................................................................................8
1.2 Related Troubleshooting Cases..........................................................................................................................8
1.2.1 VPNs Configured with the Same VPN Target Cannot Communicate......................................................9
1.2.2 Ping Between the PEs on a VPN Fails....................................................................................................11
1.2.3 Communications Between the VPN and the Public Network Fail on a Device......................................12
1.2.4 VPN Services Are Interrupted Because the Link Between an ABR and a BAS Fails in a Full-meshed
NSSA................................................................................................................................................................18
1.2.5 A Routing Loop Occurs After a Sham Link Is Established Between PEs..............................................20
1.2.6 VPN Routes Are Incorrectly Learnt in an Inter-AS VPN Option B Setup Because the Mask of the
Loopback Address on an Intermediate Router Is Incorrect..............................................................................23
1.2.7 PEs Cannot Learn Routes After the policy vpn-target Command Is Configured on an RR..................24
1.2.8 VPN Routing Table on the PE Does Not Contain Any Route Sent from the Peer PE............................26
1.2.9 CEs Cannot Ping Through Each Other....................................................................................................28
1.2.10 Failed to transmit Large Packets of the Private Network......................................................................29
1.2.11 PE Fails to Ping Through the Remote CE Network Segment...............................................................30
1.2.12 CEs in the Inter-AS IPv6 VPN Option C Fail to Communicate with Each Other................................31
1.2.13 Private Route Flapping Occurs Frequently When a Physical Interface Alternates Between Up and Down
..........................................................................................................................................................................32
1.2.14 CE Cannot Access Some Web Servers Due to the MTU Configuration...............................................37
1.2.15 The RR Fails to Reflect VPN Routes....................................................................................................39
1.2.16 CE1 Cannot Register with CE2 Because the Maximum Number of Routes Exceed the Upper Threshold
..........................................................................................................................................................................41
1.2.17 Users Attached to a CE Cannot Access the Internet After BGP/MPLS IP VPN Services Are Deployed
..........................................................................................................................................................................43
1.2.18 VPNv4 Routes on a PE Cannot Take Effect.........................................................................................45
1.2.19 MPLS VPN Convergence Is Slow.........................................................................................................47
1.2.20 One-way Audio Occurs Between the CEs Because the vpn-target import-extcommunity Command
Is Not Configured.............................................................................................................................................48
Issue 02 (2011-09-10)


Contents
1.2.21 PEs Fail to Exchange Private Network Routes Because the Mask Set for the Loopback Interface Is Not
a 32-bit Mask....................................................................................................................................................50
1.2.22 Some MPLS VPN Services on a Device Become Abnormal After the Service Cutover......................52
2 VPLS Troubleshooting...............................................................................................................56
2.1 VSI of Martini VPLS Cannot Go Up...............................................................................................................57
2.1.1 Common Causes......................................................................................................................................57
2.1.2 Troubleshooting Flowchart......................................................................................................................57
2.1.3 Troubleshooting Procedure......................................................................................................................59
2.1.4 Relevant Alarms and Logs......................................................................................................................61
2.2 VSI of Kompella VPLS Cannot Go Up............................................................................................................62
2.2.1 Common Causes......................................................................................................................................62
2.3 VSI Goes Up Only on One End........................................................................................................................66
2.3.1 Common Causes......................................................................................................................................66
2.4 A Huawei Device Cannot Establish a PW with Another Vendor's Device on a Kompella VPLS Network
................................................................................................................................................................................68
2.4.1 Common Causes......................................................................................................................................69
2.5 Related Troubleshooting Cases........................................................................................................................72
2.5.1 VPLS Services Fail..................................................................................................................................72
2.5.2 VSIs Cannot Be Up in LDP Signaling Mode..........................................................................................74
2.5.3 Packets Cannot Be Forwarded Successfully Between Two PEs Though VSIs Are Up..........................76
2.5.4 VSIs Cannot Be Up in BGP Signaling Mode..........................................................................................77
2.5.5 PEs Cannot Interwork Though VSIs Are Up..........................................................................................79
3 VLL Troubleshooting.................................................................................................................81
3.1 The VC of Martini VLL Cannot Be Up...........................................................................................................82
3.1.1 Common Causes......................................................................................................................................82
3.2 The VC of Kompella VLL Cannot Be Up........................................................................................................87
3.2.1 Common Causes......................................................................................................................................87
Issue 02 (2011-09-10)

vi

Contents
3.3 A PW of Kompella VLL Cannot Be Up When the AC Interfaces at Both Ends of the PW Are Ethernet SubInterfaces and Adopt the tagged Encapsulation Type............................................................................................92
3.3.1 Common Causes......................................................................................................................................92
3.4 The VC Cannot Be Up When a Huawei Device Communicates with a Non-Huawei Device Through Kompella
VLL........................................................................................................................................................................93
3.4.1 Common Causes......................................................................................................................................93
3.5 Related Troubleshooting Cases........................................................................................................................94
3.5.1 VC Under the Interface Is Missing After the Link Layer Protocol Changes..........................................95
3.5.2 Both the Session and the AC Are Up, But the VC Cannot Be Up..........................................................97
3.5.3 Ethernet and ATM are interconnected and the VC Is Up, But the Ping Between CEs Fails................101
3.5.4 CEs Cannot Communicate by Using the Accessing Mode of VLAN...................................................103
3.5.5 CEs Cannot Access Each Other Though the Static VC Is Up...............................................................103
3.5.6 Large Packets Are Lost in the Transmission Between CEs at Both Ends of L2VPN...........................105
3.5.7 Failed to Establish the MPLS LDP Session Between PEs When Using RIP-1 in the L2VPN Backbone
Network..........................................................................................................................................................105
4 PWE3 Troubleshooting.............................................................................................................108
4.1 The PW Cannot Be Up...................................................................................................................................109
4.1.1 Common Causes....................................................................................................................................109
4.1.2 Troubleshooting Flowchart....................................................................................................................109
4.1.3 Troubleshooting Procedure....................................................................................................................111
4.1.4 Relevant Alarms and Logs....................................................................................................................114
4.2 Related Troubleshooting Cases......................................................................................................................114
4.2.1 PW Attributes Cannot Be Changed by Using the reset pw Command.................................................114
4.2.2 VPN Services Between Two PEs Are Unavailable...............................................................................117
4.2.3 Failed to Establish OSPF Neighborhood Between CEs........................................................................119
5 L2VPN IP RAN Troubleshooting...........................................................................................121

5.1 Packets Are Lost or Duplicate Packets Are Received on an Integrated IP RAN with the Networking of HVPLS
+ L3VPN/IP..........................................................................................................................................................122
5.1.1 Common Causes....................................................................................................................................122
5.2 Packets Are Lost, Duplicate Packets Are Received, or Traffic Is Interrupted After a Primary/Secondary PW
Switchover on a BTB IP RAN with the Networking of PWE3 + (VSI + L3VPN)..............................................125
5.2.1 Common Causes....................................................................................................................................125
Issue 02 (2011-09-10)

vii

Contents
5.3 Packets Are Lost or Traffic Is Interrupted on a BTB IP RAN with the Networking of HVPLS + L3VPN
..............................................................................................................................................................................129
5.3.1 Common Causes....................................................................................................................................129
5.4 L2VPN Traffic Is Interrupted After AC Switchover on the IP RAN in PW Redundancy + APS 1:1 Mode with
TDM/ATM Base Stations.....................................................................................................................................132
5.4.1 Common Causes....................................................................................................................................132
5.5 Trouble Cases.................................................................................................................................................134
5.5.1 Too Many Packets Are Lost Because ignore-standby-state Is Not Configured in the peer Command
........................................................................................................................................................................134
5.5.2 Traffic Is Interrupted After Primary/Secondary PW Switchover on a BTB IP RAN - PWE3 + (VSI + IP)
........................................................................................................................................................................135
Issue 02 (2011-09-10)

viii

1 L3VPN Troubleshooting
L3VPN Troubleshooting
About This Chapter

This chapter describes common causes of L3VPN faults and provides the corresponding
troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.
1.1 BGP Private Network Traffic Is Interrupted
1.2 Related Troubleshooting Cases
Issue 02 (2011-09-10)


1.1 BGP Private Network Traffic Is Interrupted

1.1.1 Common Causes
This troubleshooting case describes how to clear the fault that BGP private network routes is
interrupted when the BGP peer relationship is normal.
This fault is commonly caused by one of the following causes:
l
Routes are inactive because their next hops are unreachable.
Routes fail to be advertised or received because routing policies are configured incorrectly.
Private network routes fail to be advertised because the number of labels exceeds the upper
limit.
Routes are inactive because they fail to be iterated to a tunnel.
Routes fail to be added to the VPN routing table because the configured import route-target
(RT) and export RT do not match.
The received routes are dropped because there is an upper limit on the number of routes on
the device.
1.1.2 Troubleshooting Flowchart

BGP private network traffic is interrupted after the BGP protocol is configured.
Figure 1-1 shows the troubleshooting flowchart.
Issue 02 (2011-09-10)


Figure 1-1 Troubleshooting flowchart for interruption of BGP private network traffic
The BGP private network
traffic is interrupted
Is the next hop of the

VPN route reachable?
No
Ensure that the next

hop is reachable
Is fault rectified?
Yes
No
Yes
Is the routing policy is

configured correctly?
No
Correctly configure the

routing policy
Yes
Is fault rectified?
No
Yes
Does the
Number of labels exceed the
upper limit?
Yes
Reduce the number of

routes or configure the
device to assign a label
to each instance
Yes
Is fault rectified?
No
No
Is the tunnel iterated

successfully?
No
Ensure that the tunnel

exists
Is fault rectified?
Yes
No
Yes
Does the export RT

match the import RT?
No
Ensure that they match
Is fault rectified?
Yes
No
Yes
Does the number
of routes exceed the upper
limit?
Yes
Reduce the number of

routes or increase the
upper limit of routes
Yes
Is fault rectified?
No
No
Seek technical support
End
1.1.3 Troubleshooting Procedure

NOTE
Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct
the fault, you will have a record of your actions to provide Huawei technical support personnel.
Issue 02 (2011-09-10)


Procedure
Step 1 Check that next hops of routes are reachable.
Run the display bgp vpnv4 vpn-instance vpn-instance-name routing-table ipv4-address
[ mask | mask-length ] command on the PE that sends routes (that is, the local PE) to check
whether the target route exists. ipv4-address specifies the prefix of the target route.
l If the target route does not exist, check whether the route of a CE is advertised to the local
PE.
l If the target route exists, check whether it is active. The following is an example:
Assume that the target route is a route to 1.1.1.1/32. The following command output shows that
this route is active and selected. The original next hop and iterated next hop of this route are
3.3.3.3 and 20.1.1.2 respectively.
<HUAWEI> display bgp vpnv4 vpn-instance vpna routing-table 1.1.1.1
BGP local router ID : 20.1.1.2
Local AS number : 100
Paths:
1 available, 1 best, 1 select
BGP routing table entry information of 1.1.1.1/32:
From: 20.1.1.1 (1.1.1.1)
Route Duration: 00h00m03s
Relay IP Nexthop: 20.1.1.2
Relay IP Out-Interface: Pos1/0/0
Original nexthop: 3.3.3.3
Qos information : 0x0
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal,
best, select, active, pre 255
Not advertised to any peer yet
If the target route is inactive, check whether there is a route to the original next hop in the
IP routing table. If there is no route to the original next hop, it indicates that the BGP route
is not advertised because its next hop is unreachable. Then, find out why there is no route
to the original next hop (this fault is generally associated with IGP or static routes).
If the target route is active but not selected, check whether there is a route with a higher
protocol preference in the IP routing table. If there is a route with a higher protocol
preference, consider whether or not to import it into BGP or adjust its protocol preference.
If there is no route with a higher protocol preference, contact Huawei technical support
personnel.
NOTE
In the BGP routing table, multiple routes may have the same prefix. But only one of these routes can
be selected, and only the selected route is added to the IP routing table and sent to the peer. When
an optimal route needs to be selected from among BGP routes and other protocol routes, the route
with the highest protocol preference is selected.
If the target route is active and selected but there is no information indicating that this route
is sent to the remote PE, perform Step 2 to check the outbound policy applied to the local
PE.
Run the display bgp vpnv4 all routing-table network { mask | mask-length } command on the
remote PE to check whether it has received the target route.
l
If the remote PE has received the target route, perform Step 1 again to check whether the
next hop of the route is reachable and whether this route is selected.
If the remote PE has not received the target route, perform Step 2 to check the inbound
policy of the remote PE.
Issue 02 (2011-09-10)


Step 2 Check that routing policies are configured correctly.

Run the display current-configuration configuration bgp command on the local PE and
remote PE to check whether inbound and outbound policies are configured.
NOTE
You only need to focus on peers of the BGP-VPNv4 address family or BGP-VPN instance address family
in this troubleshooting case because the private network traffic is interrupted.
<HUAWEI> display current-configuration configuration bgp
#
bgp 100
peer 1.1.1.1 as-number 200
#
ipv4-family unicast
undo synchronization
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
peer 1.1.1.1 filter-policy acl-name acl-name import
peer 1.1.1.1 filter-policy acl-name acl-name export
peer 1.1.1.1 as-path-filter 1 import
peer 1.1.1.1 as-path-filter 1 export
peer 1.1.1.1 ip-prefix prefix-name import
peer 1.1.1.1 ip-prefix prefix-name export
peer 1.1.1.1 route-policy policy-name import
peer 1.1.1.1 route-policy policy-name export
#
ipv4-family vpn-instance vpna
peer 10.1.1.1 filter-policy acl-name acl-name import
peer 10.1.1.1 filter-policy acl-name acl-name export
peer 10.1.1.1 as-path-filter 1 import
peer 10.1.1.1 as-path-filter 1 export
peer 10.1.1.1 ip-prefix prefix-name import
peer 10.1.1.1 ip-prefix prefix-name export
peer 10.1.1.1 route-policy policy-name import
peer 10.1.1.1 route-policy policy-name export
#
return
If inbound and outbound policies are configured on the two devices, check whether the
target route fails to be transmitted because it is filtered by these policies. For detailed
configurations of a routing policy, see the HUAWEI NetEngine80E/40E Configuration
Guide - IP Routing.
If inbound and outbound policies are not configured on the two devices, go to Step 3.
Step 3 Check that routes can be iterated to a tunnel.

Run the display bgp vpnv4 all routing-table ipv4-address [ mask | mask-length ] command on
the remote PE to check whether the target route can be iterated to a tunnel.
Assume that the target route is a route to 50.1.1.2/32. If the Relay Tunnel Out-Interface field
and Relay token field in the command output are not empty, it indicates that this route can be
iterated to a tunnel.
<HUAWEI> dis bgp vpnv4 all routing-table 50.1.1.2
Total routes of Route Distinguisher(1:2): 1
Label information (Received/Applied): 13316/NULL
From: 1.1.1.1 (1.1.1.1)
Issue 02 (2011-09-10)



Relay IP Nexthop: 20.1.1.1
Relay IP Out-Interface: Pos1/0/0
Relay Tunnel Out-Interface: Pos1/0/0
Relay token: 0x1002
Ext-Community:RT <1 : 1>
best, select, pre 255
Total routes of vpn-instance vpna: 1
From: 1.1.1.1 (1.1.1.1)
Relay Tunnel Out-Interface: Pos1/0/0
Relay token: 0x1002
best, select, active, pre 255
If the target route fails to be iterated to a tunnel, run the display ip vpn-instance
verbose [ vpn-instance-name ] command to check the Tunnel Policy field. If this field is
not displayed, it indicates that the VPN instance selects an LDP LSP or no tunnel policy is
configured for the VPN instance. If the VPN instance selects an MPLS-TE tunnel, a tunnel
policy must be configured. The value of the Tunnel Policy Name field indicates the tunnel
policy of the VPN instance. You can view details of the tunnel policy by running the display
this command in the corresponding tunnel policy view.
[HUAWEI-tunnel-policy-p1] display this
#
tunnel-policy p1
tunnel select-seq cr-lsp load-balance-number 1
#
NOTE
If the tunnel binding destination dest-ip-address te { tunnel interface-number } command is

configured in the tunnel policy view, you also need to configure the mpls te reserved-for-binding
command in the tunnel interface view.
If the tunnel between both ends is not Up, refer to the session LDP LSP Goes Down or
TE Tunnel Is Down to locate the fault and ensure that the tunnel goes Up.
l
If the target route can be iterated to a tunnel, go to Step 4.
Step 4 Check whether routes fail to be added to the VPN routing table because the configured import
RT and export RT do not match.
Run the display current-configuration configuration vpn-instance command on the local PE
and remote PE to check whether routes fail to be added to the VPN routing table of the remote
PE after being sent to the remote PE because the export RT of the local VPN instance does not
match the import RT of the remote VPN instance.
export-extcommunity indicates an export RT, and import-extcommunity indicates an import RT.
<HUAWEI> display current-configuration configuration vpn-instance
#
ip vpn-instance vpna
route-distinguisher 1:1
apply-label per-instance
vpn-target 1:1 export-extcommunity
vpn-target 1:1 import-extcommunity
Issue 02 (2011-09-10)


ip vpn-instance vpnb
#
return
l If the export RT of the local VPN instance does not match the import RT of the remote VPN
instance, configure matching VPN-targets in the VPN instance.
l If the export RT of the local VPN instance matches the import RT of the remote VPN instance,
go to Step 5.
Step 5 Check that the number of labels is lower than the upper limit.
Check whether MPLS is enabled on the local PE. Then, run the display bgp vpnv4 all routingtable ipv4-address [ mask | mask-length ] command to check whether the target route is assigned
a VPN label.
If there is no Label information field in the command output, it indicates that labels may be
insufficient. As a result, the target route is not assigned a label and is not advertised to the peer.
<HUAWEI> display bgp vpnv4 all routing-table 100.1.1.1
Imported route.
Label information (Received/Applied): NULL/13312
From: 0.0.0.0 (0.0.0.0)
Direct Out-interface: NULL0
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select, pre
255
Advertised to such 1 peers:
1.1.1.1
Total routes of vpn-instance vpna: 1
Imported route.
From: 0.0.0.0 (0.0.0.0)
Direct Out-interface: NULL0
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select, pre
60
l If labels are insufficient, run the apply-label per-instance command in the VPN instance
view to configure the device to assign one label to each instance so as to save labels. You
can also configure route summarization to reduce the number of routes.
l If labels are sufficient, go to Step 6.
Step 6 Check that the number of routes is lower than the upper limit.
If the peer is added to the peer group, run the display current-configuration configuration
bgp | include peer destination-address command or the display current-configuration
configuration bgp | include peer group-name command on the remote PE to check whether
the upper limit on the number of routes to be received is configured on the remote PE.
Issue 02 (2011-09-10)


For example, if the upper limit is set to 5, subsequent routes are dropped and a log is recorded
after the remote PE receives five routes from the local PE at 1.1.1.1.
<HUAWEI> display current-configuration configuration bgp | include peer 1.1.1.1
peer 1.1.1.1 route-limit 5 alert-only
peer 1.1.1.1 enable
If the peer is added to a peer group, there may be no configurations about the upper limit in the
command output.
<HUAWEI> display current-configuration configuration bgp | include peer 1.1.1.1
peer 1.1.1.1 group IBGP
peer 1.1.1.1 enable
peer 1.1.1.1 group IBGP
In this case, you need to run the display current-configuration configuration bgp | include
peer group-name command to check configurations of this peer group.
<HUAWEI> display current-configuration configuration bgp | include peer IBGP
peer IBGP route-limit 5 alert-only
peer IBGP enable
If the log BGP/3/ROUTPRIX_EXCEED is generated when traffic is interrupted, it indicates

that the target route is dropped because the number of routes received has exceeded the upper
limit. Then, you need to increase the upper limit.
NOTE
Changing the upper limit on the number of routes to be received from a peer interrupts the BGP peer
relationship. Therefore, it is recommended to reduce the number of sent routes by configuring route
summarization on the local device.
Step 7 Collect the following information and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedure
l Configuration files, log files, and alarm files of the devices
----End
1.1.4 Relevant Alarms and Logs

Relevant Alarms
BGP_1.3.6.1.4.1.2011.5.25.177.1.3.1 hwBgpPeerRouteNumThresholdExceed
Relevant Logs
BGP/3/ROUTPRIX_EXCEED
Issue 02 (2011-09-10)


1.2.1 VPNs Configured with the Same VPN Target Cannot

Communicate
Fault Symptom
As shown in Figure 1-2, BGP/MPLS VPN services are deployed on the network. CE1 and CE3
belong to VPN-A, and CE2 belongs to VPN-B. VPN-A and VPN-B are configured with the
same VPN target to ensure that they can communicate with each other.
After the configurations, CE1 can ping the IP address 4.4.4.9 in VPN-A successfully, but CE2
fails to ping the IP address 4.4.4.9 in VPN-A. This indicates that the communications between
VPN-A and VPN-B fail.
Figure 1-2 Networking diagram of BGP/MPLS VPN
AS: 65430
AS: 65410
VPN-A
VPN-A
Loopback1
4.4.4.9/32
CE1
GE1/0/0
GE1/0/0
Loopback1
2.2.2.9/32
GE1/0/0
POS1/0/0
PE1
172.1.1.2/24
Loopback1
1.1.1.9/32
GE2/0/0
CE3
GE1/0/0
POS2/0/0
PE2
172.2.1.1/24
POS3/0/0
172.2.1.2/24
POS3/0/0
172.1.1.1/24
Loopback1
3.3.3.9/32
P
MPLSbackbone
AS: 100
GE1/0/0
CE2
VPN-B
AS: 65420
Fault Analysis
1.
Run the display bgp peer or display bgp vpnv4 all peer command on PE1. You can find
that the BGP peer relationship between PE1 and PE2 is in the Established state.
2.
Sequentially run the display mpls ldp session command on PE1, P, and PE2. You can find
that the Status field in the command output is displayed as Operational, indicating that the
LDP sessions between PE1 and P and between P and PE2 have been established.
3.
Run the display ip vpn-instance verbose command on PE1 and PE2. You can find that
the VPN targets of VPN-A and VPN-B are the same.
Issue 02 (2011-09-10)


4.
Sequentially run the display mpls ldp lsp command on PE1, P, and PE2 to check
information about label allocation. You can find that public network labels and VPN labels
are allocated to all the nodes along the LSP between PE1 and PE2.
5.
Run the display ip interface brief command on the PEs to check IP addresses assigned to
the interfaces. You can find that VPN-B and VPN-A are bound to the same IP address.
[PE1] display ip interface brief
......
Interface
......
Gigabitethernet1/0/0
Gigabitethernet2/0/0
......
IP Address/Mask
Physical
Protocol
10.1.1.2/30
10.1.1.2/30
up
up
up
up
In the process of route cross on the PEs, VPN-B only selects the local direct route instead
of the BGP route destined for VPN-A. In addition, no prompt will be displayed when you
bind VPNs to the same IP address. After the binding, the VPNs fail to communicate with
each other.
Procedure
Step 1 On PE1 and CE2, run the system-view command to enter the system view.
Step 2 Run the interface interface-type interface-name command to enter the interface view.
Step 3 Run the ip address ip-address { mask | mask-length } command to assign an IP address to the
interface.
NOTE
Bind VPN-A and VPN-B to different IP addresses.
Step 4 Run the quit command to quit the interface view.

Step 5 Run the bgp as-number command to enter the BGP view.
Step 6 Run the ipv4-family vpn-instance vpn-instance-name command to enter the BGP VPN instance
view. Note that you do not need to perform this step on CE2.
Step 7 Run the undo peer ipv4-address command to delete the original BGP peer.
Step 8 Run the peer ipv4-address as-number as-number command to configure a new BGP peer.
After the preceding configurations, CE2 can ping CE3 successfully. The fault is cleared.
----End
Summary
A PE can learn routes of different VPNs from the local CE. If the next hop of a route with this
type is reachable or can be iterated, the PE matches the route with the Import VPN target of
another VPN instance. If the match operation succeeds, the PE adds the route to the routing table
of the VPN instance. This process is called route cross.
In this troubleshooting case, IP addresses to which two VPNs are bound are the same. As a result,
the route exchanged between the VPNs is not preferentially selected. Therefore, although the
VPN targets of these VPNs are matched, the VPN cannot communicate with each other. To
rectify the fault, ensure that the VPNs are bound to different IP addresses.
Issue 02 (2011-09-10)

10

1.2.2 Ping Between the PEs on a VPN Fails

Fault Symptom
On the BGP/MPLS VPN network shown in Figure 1-3, VPN routes fail to be exchanged between
PE1 and PE2, and both PEs cannot ping each other successfully.
Two loopback interfaces are configured on each PE. Loopback 1 interfaces on the two PEs are
assigned public IP addresses, 1.1.1.1/32 and 1.1.1.2/32, respectively. Loopback 2 interfaces on
the two PEs are bound to the VPN instance named test and assigned private network IP addresses,
10.1.1.1/24 and 10.1.1.2/24, respectively.
Figure 1-3 Networking diagram of BGP/MPLS VPN
Loopback 1
Loopback 1
PE1
Loopback 2
PE2
P1
Loopback 2
Fault Analysis
1.
Run the display ip routing-table command on PE1 and PE2 to check whether both PEs
have routes destined for each other's loopback1 interfaces. You can find that both PEs have
such routes.
2.
Run the display mpls ldp peer command on P1, and you can find that P1 establishes the
LDP sessions, with PeerID being 1.1.1.1 and 1.1.1.2. Run the display mpls lsp command
on P1, and you can find that P1 establishes LSPs with FECs being 1.1.1.1 and 1.1.1.2.
3.
Run the display bgp peer command on PE1 or PE2 to check BGP peer relationships. You
can find that PE1 or PE2 establishes IBGP peer relationships with 1.1.1.2 or 1.1.1.1, as
indicated by Established in the command output.
4.
Run the display bgp vpnv4 all peer command on PE1 or PE2 to check VPNv4 peer
relationships. You can find that PE1 or PE2 establishes VPNv4 peer relationships with
1.1.1.2 or 1.1.1.1, indicating that VPN routes can be properly advertised.
5.
After the preceding steps, run the display ip routing-table vpn-instance command on PE1
and PE2 to check the routes in the VRF, and you can find only one route destined for each
other's loopback2 interfaces, that is, 10.1.1.0/24 Direct with a 24-bit mask instead of a 32bit mask.
This indicates that both loopback2 interfaces are on the same network segment, which is
obviously incorrect. In fact, both PEs have received the VPN routes (BGP routes) destined
for each other's loopback2 interfaces. The received VPN routes, however, are on the same
network segment as that of the route 10.1.1.0/24 Direct. In this case, both PEs consider
that the received VPN routes are the same as 10.1.1.0/24 Direct, and therefore import only
10.1.1.0/24 Direct to their VPN routing tables because the direct route has a higher
preference than the BGP route. As a result, both VPN routing tables do not contain the BGP
routes, and the PEs cannot ping each other successfully.
Issue 02 (2011-09-10)

11

Procedure
Step 1 On PE1 and PE2, run the system-view command to enter the system view.
Step 2 Run the interface loopback loopback-number command to enter the loopback interface view.
loopback interface.
NOTE
Change the mask length of the loopback address to 32 bits.
After the preceding configurations, the PEs can ping each other successfully. The fault is cleared.
----End
Summary
If two routes of different protocols are destined for the same network segment, the device only
adds the one with a higher preference to the routing table.
1.2.3 Communications Between the VPN and the Public Network

Fail on a Device
Fault Symptom
As shown in Figure 1-4, the network is divided into two areas, Area-A and Area-B. Each area
has two PEs, which are configured with VRRP for the application system and Internet services,
as shown by the dotted blue line.
After the function of the communications between the VPN and the public network is enabled
on PEs in each area, you can find that the communications fail in Area-B but succeed in AreaA. Service models of the two areas are the same; the only difference is that two switches are
placed in Area-A to transparently transmit Layer 2 services between the PEs and the server.
NOTE
The servers in Area-A and Area-B respectively have two interfaces. One functions as the master and the
other the backup. The backup interface is in the inactive state and does not respond to any protocol packet.
Issue 02 (2011-09-10)

12

Figure 1-4 Networking diagram of communications failure between the VPN and the public
network on a device
Server
10.1.1.1/27
VLAN10
VLAN10
Trunk
VRRP for server
I n te rn e t
10.1.3.1/27
GE1/0/1
10.1.2.1/27
VLAN20
GE
/2 0
1
0
V
/
1 IF 2
LA /0 /2
E
NI
G AN
F2
VL
0
VRRP for Internet
GE1/0/1
VLANIF10
A-PE1
Trunk
Trunk
Trunk(slot 2)
GE1/0/1
VLANIF11
GE1/0/1
VLANIF10
A-PE2
Trunk(slot 2)
B-PE1
Area-A
WAN
B-PE2
VRRP for server
GE1/0/1
GE
VRRP
for
Internet
VLANIF11
1
2
VL /0 /
/0 / F 21
AN 2
1
I
IF 2
GE AN
1
VL
VLAN21
GE1/0/1
10.1.5.1/27
10.1.6.1/27
Area-B
I n te rn e t
Server
10.1.4.1/27
Issue 02 (2011-09-10)

13

NOTE
All IP addresses are configured as 10.X.X.X in the two areas. IP addresses bound to the VPN are considered
as IP addresses of the VPN.
Fault Analysis
Communications between the VPN and the public network can be easily implemented. You can
analyze the fault in the following steps.
1.
Run the display current-configuration command to check configurations of the PEs. You
can find that the PEs are correctly configured.
Details are shown in Table 1-1.
Table 1-1 Key configurations of the PEs
Issue 02 (2011-09-10)
A-PE1
A-PE2
B-PE1
B-PE2
Route
config
uration
ip routestatic 10.1.1.0
255.255.255.224
Vlanif10
10.1.1.10
ip routestatic vpninstance Media
10.1.3.0
255.255.255.224
10.1.2.1 public
#
ip routestatic
10.1.1.0
255.255.255.224
Vlanif10
10.1.1.1
10.1.3.0
255.255.255.224
10.1.2.1
public
#
ip routestatic
10.1.4.0
255.255.255.2
24 vpninstance
Media
10.11.4.10
ip routestatic vpninstance
Media
10.1.6.0
255.255.255.2
24 10.1.5.1
public
#
ip routestatic
10.1.4.0
255.255.255.224
vpn-instance
Media
10.11.4.10
10.1.6.0
255.255.255.224
10.1.5.1
public
#
VLAN
IF10
#
interface
Vlanif10
ip binding vpninstance Media
ip address
10.1.1.2
255.255.255.224
vrrp vrid 10
virtual-ip
10.1.1.10
vrrp vrid 10
priority 120
#
#
interface
Vlanif10
ip binding
vpn-instance
Media
ip address
10.1.1.3
255.255.255.224
vrrp vrid 10
virtual-ip
10.1.1.10
#
VLAN
IF20
#
interface
Vlanif20
ip address
10.1.2.2
255.255.255.224
vrrp vrid 20
virtual-ip
10.1.2.10
vrrp vrid 20
priority 120
#
#
interface
Vlanif20
ip address
10.1.2.3
255.255.255.224
vrrp vrid 20
virtual-ip
10.1.2.10
#

14

A-PE1
A-PE2
B-PE1
B-PE2
VLAN
IF11
#
interface
Vlanif11
ip binding
vpn-instance
Media
ip address
10.1.4.2
255.255.255.2
24
vrrp vrid 11
virtual-ip
10.1.4.10
vrrp vrid 11
priority 120
#
#
interface
Vlanif11
ip binding
vpn-instance
Media
ip address
10.1.4.3
255.255.255.224
vrrp vrid 11
virtual-ip
10.1.4.10
#
VLAN
IF21
#
interface
Vlanif21
ip address
10.1.5.2
255.255.255.2
24
vrrp vrid 21
virtual-ip
10.1.5.10
vrrp vrid 21
priority 120
#
#
interface
Vlanif21
ip address
10.1.5.3
255.255.255.224
vrrp vrid 21
virtual-ip
10.1.5.10
#
You can find that configurations of Area-A and Area-B are similar. Because devices in
Area-A function normally, you can conclude that the configuration principle for Area-B is
correct.
2.
Run the display ip routing-table command on B-PE2 to check the route destined for
10.1.4.1. You can find that the route is a network segment route, with the outgoing interface
as VLANIF11, and B-PE2 selects a member interface of VLAN 11, that is, GE 1/0/1, as
the actual outgoing interface.
3.
Run the display arp slot 1 command to check ARP entries of GE 1/0/1. You can find that
there is no ARP entry for 10.1.4.1.
4.
Run the display arp slot 2 command to check ARP entries of the interface board in slot 2.
You can find that the outgoing interface of the ARP entry for 10.1.4.1 is an Eth-Trunk (the
Eth-Trunk connects B-PE1 and B-PE2 and transmits VRRP protocol packets). After the
preceding steps, you can conclude that the missing of the ARP entry leads to the failure of
the communications between the VPN and the public network (to be specific, from the
public network to the VPN).
5.
The cause for the missing of the ARP entry on the interface board in slot 1 is shown as
follows:
(1) The static route of B-PE2 is a network segment route, with the outgoing interface
being VLANIF11. As a result, the specific host route cannot be obtained in the public
network.
(2) When a device in the public network needs to access 10.1.4.1, B-PE2 finds that the
outgoing interface is VLANIF11. Because the static route (ip route-static 10.1.4.0
255.255.255.224 vpn-instance Media 10.1.4.10) is configured, B-PE2 randomly
Issue 02 (2011-09-10)

15

selects a member interface of VLANIF11 as the outgoing interface (in this

troubleshooting case, the selected member interface is GE1/0/1), and sends ARP
requests and learns corresponding ARP entries through the member interface.
(3) The server 10.1.4.1 has two interfaces (master and backup). The master interface is
in the Active state and connects to B-PE1, and the backup interface is in the Inactive
state and connects to B-PE2. The backup interface does not process any protocol
packet. Therefore, after the server 10.1.4.1 receives an ARP request from B-PE2
through the backup interface, the application system does not response to this ARP
request. In this case, although the interface of B-PE2, that is, GE 1/0/1, is directly
connected to 10.1.4.1, it cannot receive the ARP response from 10.1.4.1, and
consequently no corresponding ARP entry can be generated on GE 1/0/1. Since the
ARP entry is missing, communications from the public network to the VPN fail.
(4) The ARP response of the server 10.1.4.1 can only be sent to GE 1/0/1 of B-PE1 through
the master interface. The master interface is added to VLAN 11, and the Eth-Trunk
of B-PE1 is also added to VLAN 11; therefore, the ARP response is sent to B-PE2
through the Eth-Trunk. As a result, when checking the ARP entries of the interface
board in slot 2 on B-PE2, you can find that the outgoing interface of the ARP entry
for 10.1.4.1 is the Eth-trunk, as shown in Figure 1-5.
Issue 02 (2011-09-10)

16

Figure 1-5 Networking diagram of ARP request and response
Server
10.1.1.1/27
VLAN10
Active
Inactive
VLAN10
Trunk
I n t e rn e t
Area-A
10.1.3.1/27
GE1/0/1
VLANIF10
GE1/0/1
10.1.2.1/27
VLAN20
G
/2
VL E1/
1/0 F20
E
AN 0/2
G A NI
IF2
VL
0
A-PE1
A-PE2
Trunk(slot 2)
Trunk
B-PE1
GE1/0/1
VLANIF10
WAN
Trunk
Trunk(slot 2) VLAN 11
B-PE2
GE1/0/1
2
/
0
1/ 21 VLANIF11
E
G NIF
A
VL
GE1/0/1 G
VLANIF11 VL E1/0
AN /2
IF2
1
VLAN21
GE1/0/1
10.1.5.1/27
10.1.6.1/27
Area-B
I n t e rn e t
Inactive
Server
10.1.4.1/27
Active
ARP request
ARP reply
Issue 02 (2011-09-10)

17

The cause for the successful communications between the VPN and the public network
in Area-A is that switches are placed in Area-A to transparently transmit Layer 2
services, as shown in Figure 1-5.
Usually, after learning an ARP entry, a VLANIF interface generates a 32-bit host route for
selecting the outgoing interface. If a PE is configured with a static route, the VLANIF interface
has to randomly selects an outgoing interface, and cannot correctly generate a 32-bit host route.
To sum up, in this troubleshooting case, after a static network segment route is configured on
B-PE2, B-PE2 randomly selects a member interface of the outgoing interface (VLANIF11) to
forward packets. If the member interface is incorrectly selected, the communications between
the VPN and the public network fail. In the troubleshooting case, the ARP entry learning process
is normal; therefore, the fault is caused by the configuration of the static network segment route.
Procedure
Step 1 Run the system-view command on B-PE2 to enter the system view.
Step 2 Run the undo ip route-static 10.1.4.0 255.255.255.224 vpn-instance Media 10.1.4.10
command on B-PE2 to delete the static route for communications between the VPN and the
public network.
Step 3 Run the ip route-static 10.1.4.1 255.255.255.255 vpn-instance Media 10.1.4.1 command on
B-PE2 to reconfigure the static route for communications between the VPN and the public
network.
After the preceding configuration, you can find that communications between the VPN and the
public network are implemented. The fault is thus rectified.
----End
Summary
When configuring the function of communications between the VPN and the public network,
you can only configure a 32-bit host route if a VLANIF interface functions as the outgoing
interface, instead of a network segment route. Otherwise, a member interface of the VLANIF
interface is randomly selected as the outgoing interface, and the preceding fault occurs.
1.2.4 VPN Services Are Interrupted Because the Link Between an

ABR and a BAS Fails in a Full-meshed NSSA
Fault Symptom
As shown in Figure 1-6, ABR1, ABR2, BAS1, and BAS2 form a full-meshed network. All
routers run OSPF, and the AS is divided into two areas, area 0 and area 1. Area 0 functions as
the backbone area, consisting of ABR1 and ABR2. Area 1 is configured as an NSSA, consisting
of two ABRs and two BASs.
All links are configured with MPLS LDP to transmit MPLS L3VPN services. Considering the
limited capability of the BASs, an upper limit on LSPs is set on the BASs and the BASs are
configured not to function as transit nodes.
When the link between ABR1 and BAS1 fails, VPN services between them are interrupted.
Issue 02 (2011-09-10)

18

Figure 1-6 Networking diagram of the OSPF NSSA
Loopback0
1.1.1.1/32
Loopback0
2.2.2.2/32
Area0
ABR2
ABR1
Area1
NSSA
BAS1
BAS2
Loopback0
3.3.3.3/32
Loopback0
4.4.4.4/32
Fault Analysis
1.
Run the display ospf routing command on ABR1 to check OSPF routing information. You
can find that Loopback0 of ABR1 is added to area 0. The rule for selecting OSPF routes
defines that intra-area OSPF routes are preferentially selected. Therefore, the IGP path from
ABR1 to BAS1 is ABR1 -> BAS2 -> ABR2 -> BAS1.
2.
Run the display mpls ldp lsp command on BAS2 to check information about label
allocation. You can find that the incoming/outgoing label (In/OutLabel) of the LSP is
NULL/**, indicating that BAS2 does not allocate a label to the previous hop ABR1. This
is because BAS2 does not function as a transit node to allocate a label to Loopback0 of
ABR1. BAS2 cannot receive the public network label from ABR1 and therefore VPN
services are interrupted.
Procedure
Step 1 Run the system-view command to enter the system view.
Create separate sub-interfaces on ABR1 and ABR2, assign IP addresses to the two subinterfaces, and add the sub-interfaces to area 1 (an NSSA).
Step 2 Run the interface interface-type interface-number.subinterface-number command to create a
sub-interface.
Step 3 Run the ip address command to assign an IP address to the sub-interface.
Step 4 Run the quit command to return to the system view.
Step 5 Run the ospf process-id command to enter the OSPF view.
Step 6 Run the area area-id command to enter the view of OSPF area 1.
Step 7 Run the network ip-address wildcard-mask command to add the sub-interfaces to area 1.
Step 8 Run the nssa command to configure area 1 as an NSSA.
Issue 02 (2011-09-10)

19

After the preceding configurations, ABR1 can ping BAS1 successfully. The fault is cleared.
----End
Summary
Loopback interfaces should be added to the correct area.
1.2.5 A Routing Loop Occurs After a Sham Link Is Established

Between PEs
Fault Symptom
As shown in Figure 1-7, OSPF runs on the network, and CE1 and CE2 respectively access PE1
and PE2. A sham link is established between PE3 and PE4 to transmit LSAs.PE1 and PE2 are
not connected through Layer 3 interfaces. On CEs, GE1/0/0 is configured to belong to area 0,
and GE2/0/0 is configured to belong to area 1. The cost of the link between CE2 and PE2 is set
larger, ensuring that the traffic is preferentially transmitted through the link between CE1 and
PE1. Other links adopt the default cost value. VRRP runs on GE2/0/0 of CE2, with CE1 as the
VRRP gateway.
In the preceding networking, it is found that devices on the network segment 10.1.1.0/24 can
access PE3 and PE1, but cannot access PE4 and PE2, and devices on the office network can
access PE4, PE2, PE3, and PE1.
Figure 1-7 Networking diagram of the OSPF sham link
Cost 1
PE4
PE3
GE2/0/0
20.1.2.6/24
Cost 1
Exit
Network
Office
PE1
sham link
GE1/0/0
20.1.2.5/30
Cost 10
GE1/0/0
20.1.2.9/30
Cost 1
GE2/0/0
20.1.2.1/30
Cost 1
PE2
Exit
GE2/0/0 GE2/0/0
Network
GE1/0/0 172.16.1.1/24 172.17.1.1/24 GE1/0/0
Office
20.1.2.13/30
10.1.2.17/30
Cost 10
Cost 20
CE1
CE2
GE2/0/0
10.1.1.1/24
Cost 10
Area1
GE2/0/0
10.1.1.2/24
Cost 20
Fault Analysis
The possible causes are as follows:
Issue 02 (2011-09-10)

20

A firewall exists on the network and packets are filtered by the firewall.
A link fault occurs on the network.
The routing planning is improper.
A device fails.
Sequentially check whether the preceding faults exist, and you can find the following:
1.
No firewall exists on the network.
2.
The ping operation succeeds on all direct links of the network, indicating that these links
are in the normal state.
3.
Run the tracert [ -a source-ip-address ] host command to determine the gateways through
which the packets sent from a device on the network segment 10.1.1.0/24 to CE2. You can
find that a loop is formed between PE2 and PE4. Theoretically, OSPF is a loop-free
protocol. Why does the loop occur?
4.
Run the display ip routing-table command to view routing information about PE2. You
can find that the next hop of the route destined for the network segment 10.1.1.0/24 is PE4,
and the cost is 32. In addition, you can find that the cost of the link between PE2 and CE2
is 20. In this case, why does PE2 preferentially select the route with CE2 as the next hop?
5.
Run the ping [ -a source-ip-address ] host command to check the connectivity between
PE2 and CE2, and you can find that the ping operation succeeds and the link is normal.
Run the display ospf peer command to check information about the OSPF peer
relationships in each OSPF area. You can find that all OSPF peer relationships (including
the OSPF peer relationship between PE2 and CE2) are in the full state.
6.
Run the display ospf lsdb command to check the OSPF LSDB on PE2, and you can find
that the LSDB contains the LSAs that are advertised by CE1 and CE2 and destined for
10.1.1.0/24. The LSA advertised by CE2 has the metric of 20; the metric value, however,
only indicates the cost of CE2 to reach 10.1.1.0/24, instead of the cost of PE2 to reach
10.1.1.0/24. After being added with the cost value between CE2 and PE2, that is, 20, the
cost of PE2 to reach 10.1.1.0/24 is 40 (20+20), which is larger than the cost of the path PE2
-> PE4 -> PE3 -> PE1 -> CE1, that is, 32 (10+1+1+10+10).
Similarly, you can find that the cost of the path PE4 -> PE3 -> PE1 -> CE1, that is, 22, is
smaller than the cost of the path PE4 -> PE2 -> CE2, that is 41. In this case, PE4 must select
PE3, instead of CE2, as the next hop.
7.
Run the display ospf lsdb command to check the OSPF LSDB on PE4. You can find the
LSA that is advertised by CE1 and destined for 10.1.1.0/24. Nevertheless, run the display
ip routing-table 10.1.1.0 24 verbose command on PE4, and you can find two routes
destined for 10.1.1.0/24. One is an OSPF route in the active state, with the next hop being
PE2, and the other is a BGP route in the inactive state, with the next hop being PE2.
The cause for the route PE4 -> PE3 -> PE1 -> CE1 not being selected is that the sham link
is established between PE3 and PE4, and the route learnt from the sham link is considered
as a BGP route. The preference of BGP routes is 255, whereas the preference of OSPF
routes is 10. Therefore, PE4 preferentially selects the route learnt from PE2.
To sum up, the sham link is handled specially on PEs, and the type of the route learnt from
the sham link is BGP, leading to the routing loop between PE2 and PE4 on the network.
Procedure
l
Solution 1:
1.
Issue 02 (2011-09-10)
Run the system-view command to enter the system view.

21

2.
Run the bgp command to enter the BGP view.
3.
Run the ipv4-family unicast command to enter the IPv4 unicast address family view.
4.
Run the preference { external internal local | route-policy route-policy-name }

command to modify the BGP preference on PE4, enabling PE4 to preferentially select
the route learnt from the sham link.
NOTE
This solution eliminates the existing loop, but cannot prevent loops if the networking is changed.
Solution 2:
1.
2.
Run the ospf process-id [ router-id router-id ] vpn-instance vpn-instance-name

command to enter the OSPF view.
3.
Run the area area-id command to enter the OSPF area view.
4.
Run the sham-link source-ip-address destination-ip-address [ smart-discover ]

[ simple [ [ plain ] plain-text | cipher cipher-text ] | { md5 | hmac-md5 } [ key-id
{ plain plain-text | [ cipher ] cipher-text } ] | authentication-null ] [ cost cost ]
command to modify the cost of the sham link on PE4, disabling PE2 from
preferentially learning the route from PE4 and thus eliminating the loop.
NOTE
Similar to solution 1, solution 2 cannot prevent loops if the networking is changed.
Solution 3:
1.
This solution is to add a VPN route between PE3 and PE4, which fundamentally
prevents loops.
NOTE
This solution actually takes PEs as MCEs and does not use MPLS VPN, which is inconvenient for
MPLS domain expansion.
Solution 4:
This solution is to optimize the existing OAM network. The specific measure is to set up
a Layer 3 link between PE1 and PE2 and add this link to area 0. This solution can not only
solve the current problem, but also prevent the traffic on the network (such as the traffic
between CE1 and PE2) from being transmitted between the PEs. Details are as follows:
1.
2.
Run the ospf process-id command to enter the OSPF view.
3.
Run the area 0 command to enter the view of OSPF area 0.
4.
Run the network ip-address wildcard-mask command to add the Layer 3 link to area
0.
l
NOTE
You can adopt the second solution at the beginning because this solution causes less network change.
Later, you can adopt the fourth solution to completely solve the problem.
You can change the cost of the sham link to 100 on PE3 and PE4, and on PE2, change the next hop of the
route destined for 10.1.1.0/24 to 10.1.2.17/30. After the preceding change, devices on the network segment
10.1.1.0/24 can access CE2, PE2, and PE4. Devices on other network segments can also access CE2, PE2,
and PE4.
----End
Issue 02 (2011-09-10)

22

Summary
It is recommended that the sham link be avoided in network planning to prevent routing loops.
1.2.6 VPN Routes Are Incorrectly Learnt in an Inter-AS VPN Option

B Setup Because the Mask of the Loopback Address on an
Intermediate Router Is Incorrect
Fault Symptom
As shown in Figure 1-8. The Inter-AS VPN Option B is Setup, and the EBGP peer relationship
is established between PE2 and CE2. It is found that CE2 can learn the route to 2.2.2.5 from
CE1, but CE1 cannot learn the route to 1.1.1.5 from CE2.
Figure 1-8 Networking diagram of inter-AS VPN Option B mode
Loopback0
1.1.1.2/32
AS 100
Loopback0
1.1.1.1/32
ASBR1
Loopback0
1.1.1.3/32
AS 200
Loopback0
1.1.1.4/32
ASBR2
PE2
PE1
CE1
Loopback0
2.2.2.5/32
AS 300
CE2
AS 300
Loopback0
1.1.1.5/32
Fault Analysis
NOTE
In normal situations, routes are learnt in a bidirectional manner. With inter-AS VPN Option B, VPN routes
are saved on intermediate ASBRs. To locate the fault, you need to check BGP VPNv4 routes on devices
along the path to the device where the route to 1.1.1.5 is lost.
1.
Issue 02 (2011-09-10)
Run the display bgp vpnv4 all routing-table command sequentially on PE2, ASBR2,
ASBR1, and PE1 to identify the device on which the VPNv4 route to 1.1.1.5 is lost. You
can find that all the devices have this route, but PE1 does not take this route as an optimal
route.
23

2.
Run the display current-configuration command on ASBR1. You can find that the IP
address of Loopback0 on ASBR1 is configured as 1.1.1.2 255.255.255.252. LDP labels are
allocated only to host routes with a 32-bit mask by default. Loopback0 on ASBR1 has an
IP address with a 30-bit mask and therefore it is not assigned an LDP label and the
corresponding LSPs cannot be established. When PE1 learns a VPNv4 route, it checks
whether the corresponding LSP is valid. If the LSP is not fully established because of
incomplete label allocation, the VPNv4 route cannot be added to the VPN routing table.
Procedure
Step 2 Run the interface loopback loopback-number command to enter the loopback interface view.
loopback interface.
NOTE
Change the mask length of the loopback address to 32 bits.
Step 4 Run the reset mpls ldp vpn-instance vpn-instance-name command to reset vpna. In this manner,
all interfaces, peers, sessions, LSPs, and CR-LSPs of vpna are deleted and re-created.
After the preceding configurations, run the display ip routing-table vpn-instance vpn-instancename command, and you can find that the routing table of vpna contains the route to 1.1.1.5.
Run the ping -vpn-instance vpn-instance-name -a source-ip-address command on PE1. You
can find the ping operation succeeds. The fault is cleared.
----End
Summary
When LDP is used to establish LSPs, LDP labels are allocated only to the host routes with a 32bit mask by default. If the corresponding route is not a host route, the LDP labels cannot be
correctly allocates and the LSP cannot be established.
1.2.7 PEs Cannot Learn Routes After the policy vpn-target

Command Is Configured on an RR
Fault Symptom
As shown in Figure 1-9, the same VPN instance, vpna, is configured on PE1, PE2, PE3, and
PE4. To improve network reliability, double RRs are selected from Ps in the same AS for the
VPN instance. In this manner, the two RRs back up each other and respectively reflect public
network routes and VPNv4 routes. After the configurations, PE1 and PE2 cannot learn routes
from PE3 and PE4, and PE3 and PE4 cannot learn routes from PE1 and PE2.
Issue 02 (2011-09-10)

24

Figure 1-9 Networking diagram of the VPN with double RRs
RR2
RR1
PE1
PE2
PE3
PE4
Fault Analysis
1.
Check whether a routing policy that limits route advertisement is configured on the RRs.
Run the display route-policy command on RR1 and RR2, and you can find that no RR is
configured with a routing policy that restricts route reflection and reception.
2.
Check whether route conflict occurs. Run the display ip routing-table vpn-instance
vpna command on the PEs, and you can find that there is no route conflict in vpna.
3.
Check whether the RRs are incorrectly configured. Run the display currentconfiguration command on the RRs to view BGP configurations. You can find that one
RR is configured with the policy vpn-target command in the BGP-VPNv4 address family
view.The policy vpn-target command is used to enable the VPN-Target filtering function
for received VPNv4 routes. Only the VPNv4 route whose Export VPN target attribute
matches the local Import VPN target attribute can be added to the routing table. The RR is
not configured with the VPN instance vpna; as a result, the RR does not receive the routes
with the VPN target as vpna.
Solution 1: Disable the VPN-Target filtering function for received VPNv4 routes on the
RR.
Procedure
1.
2.
Run the bgp as-number command to enter the BGP view.
3.
Run the ipv4-family vpnv4 command to enter the BGP-VPNv4 address family view.
4.
Run the undo policy vpn-target command to cancel VPN target filtering for VPNv4
routes. In this manner, all VPNv4 routes can be received.
After the preceding configurations, run the display ip routing-table command on
PE1 and PE2. You can find that the two PEs have routes destined for PE3 and PE4.
Similarly, you can find that PE3 and PE4 have routes destined for PE1 and PE2. The
fault is thus rectified.
Issue 02 (2011-09-10)
Solution 2: Configure the VPN instance vpna on the RR.

1.
2.
Run the ip vpn-instance vpn-instance-name command to create the VPN instance

vpna.
25

3.
Run the vpn-target vpn-target command to associate the VPN target with vpna.
NOTE
The vpn-target must be the same as that of vpna configured on the PEs.
After the preceding configurations, run the display ip routing-table command on

PE1 and PE2. You can find that the two PEs have routes destined for PE3 and PE4.
Similarly, you can find that PE3 and PE4 have routes destined for PE1 and PE2. The
fault is thus rectified.
----End
Summary
The policy vpn-target command needs to be used with caution.
1.2.8 VPN Routing Table on the PE Does Not Contain Any Route
Sent from the Peer PE
Fault Symptom
Figure 1-10 Networking diagram of BGP/MPLS IPv6 VPN
Loopback0
1.1.1.1/32
Loopback0
Loopback0
2.2.2.2/32
3.3.3.3/32
GE1/0/0
GE1/0/0
12.1.1.2/30
23.1.1.2/30
PE2
GE1/0/0
GE2/0/0
12.1.1.1/30
GE2/0/0
P 23.1.1.1/30
10:2:1::22/64
GE1/0/0
10:2:1::21/64
PE1
GE2/0/0
10:1:1::12/64
GE1/0/0
10:1:1::11/64
CE1
CE2
The configuration in Figure 1-10 is as follows:

l
EBGP runs on the PEs and the CEs.
An IBGP adjacency is established between PE1 and PE2 to transmit VPNv6 routing
information that contains inner labels.
An arbitrary IGP runs on PE1, the P, and PE2 to transmit routing information about the
public network.
MPLS and MPLS LDP are enabled on PE1, the P, and PE2
After the configuration is complete, PE1 can receive private network routes from CE1, but PE2
and CE2 cannot do that.
Issue 02 (2011-09-10)

26

Fault Analysis
1.
Run the display bgp vpnv6 all peer command on each PE. The command output shows
that the BGP peer relationship is in the Established state, which indicates that the peer
relationship is set up.
2.
Run the display bgp vpnv6 all routing-table peer ipv4-address received-routes
command on PE2. The command output shows that PE2 has received the VPNv6 route sent
from PE1.
3.
Run the display bgp vpnv6 vpn6-instance vpn6-instance-name routing-table ipv6address [ mask-length ] command on PE2 to view information about the tunnel to which
the specified route is iterated.
If the Relay token is 0x0, it indicates that the route to ip-address does not find the associated
tunnel. The cause is that the setup of LSP for the next hop of the route fails.
<PE2> display bgp vpnv6 vpn-instance vpna routing-table 66::66 128
Paths:
BGP routing table entry information of 66::66/128
From: 1.1.1.1 (1.1.1.1)
Relay Tunnel Out-Interface:
Relay token: 0x0
Original nexthop: ::FFFF:1.1.1.1
AS-path 65420, origin igp, MED 0, localpref 100, pref-val 0, internal, pre
255
4.
Check whether there is an LSP to the next hop (1.1.1.1).

<PE2> display mpls lsp include 1.1.1.1 32
If the display is blank, it indicates that there is no LSP to 1.1.1.1, and the LSP tunnel is not
established successfully.
5.
Check whether MPLS LDP is enabled on the interfaces between PE1 and P, and on the
interfaces between P and PE2.
[PE1] interface gigabitethernet 1/0/0
[PE1-GigabitEthernet1/0/0] display this
#
interface GigabitEthernet1/0/0
ip address 12.1.1.1 255.255.255.252
mpls
#
The preceding display shows that MPLS LDP is not enabled in the interface view.
Procedure
Step 1 Run the interface gigabitethernet 1/0/0 command on PE1 to enter the interface view.
Step 2 Run the mpls ldp command in the interface view to enable LDP on the interface.
----End
Summary
To transfer the traffic of private network across the public network, a public network tunnel is
required.
Issue 02 (2011-09-10)

27

If the setup of a public network tunnel fails, the possible reason is that MPLS LDP is not enabled
on the interface, or an LDP session is not established. As a result, the PE does not choose the
private network route sent from the peer PE as the optimal route.
1.2.9 CEs Cannot Ping Through Each Other

Fault Symptom
BGP/MPLS IPv6 VPN services are configured in the network shown in Figure 1-11. CE1 and
CE2 belong to the same IPv6 VPN. After the configuration, CE1 cannot ping through CE2.
Loopback 1
Loopback 1
PE1
PE2
P1
P2
CE1
CE2
Fault Analysis
NOTE
Take the configuration of PE2 as an example. The configuration of PE1 is similar to that of PE2, and is
not mentioned here.
1.
Run the display bgp vpnv6 all peer command on PE2 to check the IBGP peer relationship
between PE2 and PE1. You can find that the IBGP peer relationship is not set up
successfully.
2.
Check the BGP configuration. You can find that the loopback interface is not specified as
the outbound interface of the local IBGP peer session by using the peer peer-ip-address
connect-interface loopback interface-number command when the two PEs set up the
IBGP connection.
If the outbound interface is not specified for the local IBGP session, the outbound interface
of the data stream is the outbound interface of the session by default.The IBGP peer
relationship between PEs is usually set up by using the loopback interface addresses with
each having a 32-bit mask, and the source interface through which BGP packets are sent
is also set to the loopback interface.
Procedure
Step 1 Run the interface loopback interface-number in the system view.
Step 2 Run the ip address ip-address 32 command to configure an IP address for the loopback interface.
Issue 02 (2011-09-10)

28

Step 4 Run the bgp as-number command to display the BGP view.
Step 5 Run the peer peer-ip-address connect-interface loopback interface-number command to
specify the loopback interface as the outbound interface to the IBGP peer session.
Step 6 Save the configuration.
On the local CE, ping the remote CE. If the ping succeeds, it indicates that the fault is rectified.
----End
Summary
Specify the local loopback interface as the outbound interface of the local IBGP session when
configuring PE peers.
1.2.10 Failed to transmit Large Packets of the Private Network

Fault Symptom
When the Huawei device networks with devices from other vendors deploy Layer 3 MPLS IPv6
VPN service by using the Ethernet interface, it is found that the packet larger than 1492 bytes
cannot be transmitted between private network users. Users cannot access certain websites or
download files through FTP.
Run the ping command, and find that the ping fails when the payload of the specified ICMP is
larger than 1464 bytes.
Fault Analysis
1.
The default MTU of an Ethernet interface is 1500 bytes. When forwarding data, MPLS
IPv6 VPN inserts a 4-byte or 8-byte MPLS packet header between the IP header and the
Layer 2 frame header. That is, a 4-byte label is added during the forwarding between the
penultimate hop and the tail-end hop; a 8-byte label is added in data forwarding between
other P devices.
2.
The link layer does not know the MPLS processing. By default, the link layer still receives
data packets with the maximum size of 1500 bytes. Then, packets of 1492 to 1500 bytes is
too long after the MPLS packet header is added to the packets. Consequently, the link layer
cannot receive them, and data forwarding is adversely affected.
Procedure
Step 1 Adjust the MTU value of the physical interfaces on other vendors' devices. The MTU value
should be at least 1508 bytes.
Step 2 By default, an Ethernet interface on the Huawei device can send and receive large frames. No
adjustment is required on the Huawei device.
----End
Summary
When large packets cannot be received, check whether the MTU of the inbound interface is too
small.
Issue 02 (2011-09-10)

29

1.2.11 PE Fails to Ping Through the Remote CE Network Segment

Fault Symptom
vpn1
Site1
CE1
vpn1
Backbone
GE1/0/0
10::1:1:1/64
GE1/0/0
10::3:1:1/64
PE1
GE2/0/0
10::2:1:1/64
Site3
CE3
PE2
CE2
Site2
vpn1
As shown in Figure 1-12, after binding multiple private network interfaces to the same VPN,
run the ping ipv6 10::3:1:1 command on CE1 and CE2. CE1 and CE2 can ping through the
remote network segment where CE3 resides. Run the ping ipv6 vpn6-instance vpn1
10::3:1:1 command on PE1. PE1, however, cannot ping though the network segment where
CE3 resides.
Fault Analysis
Multiple private network interfaces on the ingress node (a PE) are bound to the same IPv6 VPN
instance. When the PE pings or traces the remote CE network segment, the source address of
the ICMP packet is the lowest private network address that is Up on the local PE; if the remote
CE does not import the private network address, the ICMPv6 packet cannot return.
Therefore, to ping through the remote CE segment by using the ping ipv6 vpn6-instance vpn6instance-name dest-ipv6-address command, ensure that the remote CE has all the Up private
network addresses of the local PE. If the source IP address is specified as a private network
address in the Up state on the local PE by using the ping command, and the private network
address is imported to the remote CE, the PE can ping through the remote CE network segment.
Procedure
Step 1 Ensure that the remote CE has all the private network addresses in the Up state that belong to
the local PE.
Issue 02 (2011-09-10)

30

Step 2 Run the import-route direct command in BGP VPN instance view of the local PE. Ensure that
all private routes on the local PE can be advertised through MP-BGP. You can also replace the
ping ipv6 vpn6-instance vpn6-instance-name dest-ip-address command with the ping ipv6 a source-ipv6-address vpn6-instance vpn6-instance-name dest-ipv6-address command.
----End
Summary
When you ping the remote CE network segment from the local CE, it is recommended to specify
the source address of the ping packet; otherwise, the ping may fail.
1.2.12 CEs in the Inter-AS IPv6 VPN Option C Fail to Communicate

with Each Other
Fault Symptom
Figure 1-13 Networking diagram of inter-AS IPv6 VPN Option C
PE1
Backbone
AS100
ASBR1
ASBR2
CE1
Backbone
AS200
PE2
CE2
As shown in Figure 1-13, when the inter-AS VPN Option C is configured, the MP-EBGP peer
relationship is established between PE1 and PE2, but CE1 and CE2 fail to communicate with
each other.
A check of the relevant routing table and forwarding table shows that there are two IGP routes
between PE2 and ASBR2 for load balancing. An LDP LSP is established over one of the routes,
Link_A; the other route, Link_B, has no LDP LSP established over it.
Fault Analysis
If there are multiple equal-cost IGP routes to the loopback interface on a PE in the same AS as
the ASBR, the ASBR imports any one of them into BGP as the route to the PE. If the selected
route is not iterated to the corresponding LDP LSP, the ASBR discards the received data. As a
result, the CEs fail to communicate with each other.
Run the display bgp routing-table command on ASBR2 to view the BGP route to the loopback
interface on PE2. The command output shows that the route, Link_B, is selected as the optimal
route. The LDP LSP, however, is not set up over Link_B. As a result, the CEs fail to communicate
with each other.
<ASBR2> display bgp routing-table 4.4.4.9
Issue 02 (2011-09-10)

31


Paths:
Network route.
Label information (Received/Applied): NULL/13312
From: 0.0.0.0 (0.0.0.0)
Direct Out-interface: Pos3/0/0
AS-path Nil, origin igp, MED 2, pref-val 0, valid, local, best, select, pre 10
Advertised to such 1 peers:
192.1.1.1
Procedure
l
Solution 1: Delete the links along which no LDP LSPs are set up so that only the routes
associated with LDP LSPs can be imported into BGP.
Solution 2: Adjust the link costs based on the corresponding IGP to ensure that the costs
of the IGP routes imported into IBGP are not equal. Then, the route associated with an LDP
LSP can be selected as the optimal route. In the following example, OSPF is used as the
IGP.
1.
Run the interface interface-type interface-number command to enter the view of the
interface on which link costs need to be adjusted.
2.
Run the ospf cost cost command to adjust the link costs.
Solution 3: Enable MPLS and MPLS LDP on the devices along the link over which no LDP
LSP is set up and on the link interfaces to set up an LDP LSP.
1.
Run the mpls command to enable MPLS on the local end and enter the MPLS view.
2.
Run the mpls ldp command to enable LDP globally and enter the MPLS LDP view.
3.
Run the quit command to return to the system view.
4.
Run the interface interface-type interface-number command to enter the interface

view.
5.
Run the mpls command to enable MPLS on the interface.
6.
Run the mpls ldp command to enable LDP on the interface.
----End
Summary
When importing routes to the loopback interface on the PE into BGP, ensure that the routes to
be imported are associated with LDP LSPs.
1.2.13 Private Route Flapping Occurs Frequently When a Physical

Interface Alternates Between Up and Down
Fault Symptom
On the network shown in Figure 1-14, Router A, Router B, and Router C run IS-IS and are
configured with L3VPN services. After the configurations, services between Router A and
Router C flap.
Issue 02 (2011-09-10)

32

Figure 1-14 Networking diagram of frequent route flapping caused by alternation between Up
and Down of a physical interface
RouterA
GE1/0/0
RouterB
GE1/0/0
RouterC
Fault Analysis
1.
Run the display ip routing-table 1.1.1.1 and display fib 1.1.1.1 commands on Router A
to view the route type. It is found that routes are generated by IS-IS and LDP over TE is
configured.
Route Flags: R - relay, D - download to fib
-----------------------------------------------------------------------------Routing Table : Public
Summary Count : 1
Destination/Mask
Proto
Pre
1.1.1.1/32
ISIS
15
Route Entry Count: 1
Destination/Mask
Nexthop
1.1.1.1/32
1.1.1.2
2.
Cost
10
Flags NextHop
D
Interface
1.1.1.2
Flag TimeStamp
DGHU t[17635149]
Tunnel1/0/1
Interface
Tun1/0/1
Run the display isis lsdb verbose command to view the IS-IS neighborship of the device.
It is found that the IS-IS neighbor relationship is established for a long time and is stable.
This indicates that the IS-IS neighbor relationship is normal.
Database information for ISIS(100)
---------------------------------Level-2 Link State Database
LSPID
Seq Num
Checksum
Holdtime
OL
0000.0255.0239.00-00 0x00003038
0xd401
867
INTF ADDR
1.1.1.1
Router ID
1.1.1.1
3.
TunnelID
0x1008e
Length
ATT/P/
367
0/0/0
Run the display isis lsdb 0000.0255.0239.00-00 command to check whether the specific
LSP changes.
Seq Num
Checksum
Holdtime
LSPID
Length ATT/P/
OL
-----------------------------------------------------------------------------0000.0255.0239.00-00 0x00003038
0xd401
831
367
0/0/0
*(In TLV)-Leaking Route, *(By LSPID)-Self LSP, +-Self LSP(Extended),
ATT-Attached, P-Partition, OL-Overload
LSPID
Seq Num
Checksum
Holdtime
Length ATT/P/
OL
------------------------------------------------------------------------------
Issue 02 (2011-09-10)

33

0000.0255.0239.00-00 0x00003038
0xd401
829
367
0/0/0
*(In TLV)-Leaking Route, *(By LSPID)-Self LSP, +-Self LSP(Extended),
ATT-Attached, P-Partition, OL-Overload
According to the preceding information, the LSP is normal with the length and hold-time
parameters unchanged. Therefore, route flapping is not caused by IS-IS.
4.
Run the display mpls lsp include 1.1.1.1 32 command to check whether the TE tunnel
flapping occurs. It is found that the LSP to the IP address does not flap. The LDP LSP is
Up for a short time, which indicates that the LDP LSP flaps. As a result, route flapping
occurs.
-----------------------------------------------------------------------------LSP Information: RSVP LSP
------------------------------------------------------------------------------
Issue 02 (2011-09-10)
No
SessionID
IngressLsrID
LocalLspID
Tunnel-Interface
Fec
Nexthop
In-Label
Out-Label
In-Interface
Out-Interface
LspIndex
Token
LsrType
Bypass In Use
Bypass Tunnel Id
BypassTunnel
Mpls-Mtu
TimeStamp
Bfd-State
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
1
12
1.1.1.3
32778
Tunnel1/0/2
1.1.1.1/32
1.1.2.1
65542
65686
GigabitEthernet2/0/0
2123
0x700bef8
Transit
Not Exists
0x0
Tunnel Index[---]
1600
309526sec
---
No
SessionID
IngressLsrID
LocalLspID
Tunnel-Interface
Fec
Nexthop
In-Label
Out-Label
In-Interface
Out-Interface
LspIndex
Token
LsrType
Bypass In Use
Bypass Tunnel Id
BypassTunnel
Mpls-Mtu
TimeStamp
Bfd-State
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
2
12
1.1.1.2
1
Tunnel1/0/2
1.1.1.1/32
1.1.2.1
NULL
65817
---------GigabitEthernet3/0/0
2181
0x700bf18
Ingress
Not Exists
0x0
Tunnel Index[---]
1600
309524sec
---
No
SessionID
IngressLsrID
LocalLspID
Tunnel-Interface
Fec
Nexthop
In-Label
Out-Label
:
:
:
:
:
:
:
:
:
3
12
1.1.1.2
32773
Tunnel1/0/2
1.1.1.1/32
1.1.2.2
NULL
65581

34

In-Interface
: ---------Out-Interface
: GigabitEthernet2/0/0
LspIndex
: 2827
Token
: 0x80094a9
LsrType
: Ingress
Bypass In Use
: Not Exists
Bypass Tunnel Id
: 0x0
BypassTunnel
: Tunnel Index[---]
Mpls-Mtu
: 1600
TimeStamp
: 1825411sec
Bfd-State
: -------------------------------------------------------------------------------LSP Information: LDP LSP
-----------------------------------------------------------------------------No
: 4
VrfIndex
:
Fec
: 1.1.1.1/32
Nexthop
: 1.1.1.2
In-Label
: 1102
Out-Label
: 3
In-Interface
: ---------Out-Interface
: Tunnel1/0/2
LspIndex
: 72894
Token
: 0x1008f
FrrToken
: 0x0
LsrType
: Transit
Outgoing token
: 0x0
Label Operation
: SWAP
Mpls-Mtu
: -----TimeStamp
: 10sec
Bfd-State
: --No
VrfIndex
Fec
Nexthop
In-Label
Out-Label
In-Interface
Out-Interface
LspIndex
Token
FrrToken
LsrType
Outgoing token
Label Operation
Mpls-Mtu
TimeStamp
Bfd-State
5.
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
5
1.1.1.1/32
1.1.1.2
NULL
3
---------Tunnel1/0/2
72897
0x1008e
0x0
Ingress
0x0
PUSH
-----10sec
---
Run the display mpls ldp session command to view the status of the LDP neighbor. It is
found that the LDP neighbor is flapping.
LDP Session(s) in Public Network
-----------------------------------------------------------------------------Peer-ID
Status
LAM SsnRole SsnAge
KA-Sent/Rcv
-----------------------------------------------------------------------------......
1.1.1.1:0
Operational DU
Passive 000:00:00
20492/20493
......
-----------------------------------------------------------------------------TOTAL: 36 session(s) Found.
LAM : Label Advertisement Mode
SsnAge Unit : DDD:HH:MM
Issue 02 (2011-09-10)

35

6.
Run the display mpls ldp peer command to view information about the LDP peer. The
command output shows two LDP peers, namely, a remote LDP peer and a local LDP peer.
LDP Peer Information in Public network
-----------------------------------------------------------------------------Peer-ID
Transport-Address Discovery-Source
-----------------------------------------------------------------------------1.1.1.1:0
1.1.1.1
Remote Peer : otb-to-trg
-----------------------------------------------------------------------------TOTAL: 36 Peer(s) Found.
LDP Peer Information in Public network
-----------------------------------------------------------------------------Peer-ID
Transport-Address Discovery-Source
-----------------------------------------------------------------------------1.1.1.1:0
1.1.1.1
-----------------------------------------------------------------------------TOTAL: 36 Peer(s) Found.
7.
Run the display interface gigabitEthernet1/0/0 command to view the status of the
interface. It is found that the interface frequently alternates between Up and Down. As a
result, route flapping occurs.
GigabitEthernet1/0/0 current state : UP
Line protocol current state : DOWN
Description:10G_Link_to-TRG_Through_ODF 23/24
Route Port,The Maximum Transmit Unit is 1500
Internet protocol processing : disabled
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0018-82d7b2e5
The Vendor PN is SXP3101SV-H12
BW: 10G, Transceiver Mode: SingleMode
WaveLength: 1550nm, Transmission Distance: 40km
Rx Power: -4.50dBm, Tx Power: 1.14dBm
Loopback:none, LAN full-duplex mode, Pause Flowcontrol:Receive Enable and Send
Enable
Last physical up time
: 2010-05-20 21:33:42
Last physical down time : 2010-05-20 21:31:58
Statistics last cleared:2010-04-25 02:10:55
Last 300 seconds input rate: 0 bits/sec, 0 packets/sec
Last 300 seconds output rate: 0 bits/sec, 0 packets/sec
Input: 486833280327643 bytes, 720675974914 packets
Output: 66656626810850 bytes, 400094354049 packets
Input:
Unicast: 720675171257 packets, Multicast: 797735 packets
Broadcast: 5922 packets, JumboOctets: 38836146308 packets
CRC: 688 packets, Symbol: 200 packets
Overrun: 0 packets
InRangeLength: 0 packets
LongPacket: 0 packets, Jabber: 0 packets,
Fragment: 3 packets, Undersized Frame: 0 packets
RxPause: 0 packets
Output:
System: 0 packets, Overruns: 0 packets
TxPause: 0 packets
Unknown Vlan: 0 packets
GigabitEthernet1/0/0 current state : UP
Line protocol current state : DOWN
Description:10G_Link_to-TRG_Through_ODF 23/24
Route Port,The Maximum Transmit Unit is 1500
Internet protocol processing : disabled
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0018-82d7b2e5
Issue 02 (2011-09-10)

36

The Vendor PN is SXP3101SV-H12

BW: 10G, Transceiver Mode: SingleMode
WaveLength: 1550nm, Transmission Distance: 40km
Rx Power: -4.50dBm, Tx Power: 1.14dBm
Loopback:none, LAN full-duplex mode, Pause Flowcontrol:Receive Enable and Send
Enable
Last physical up time
: 2010-05-20 21:33:45
Last physical down time : 2010-05-20 21:31:43
Statistics last cleared:2010-04-25 02:10:55
Last 300 seconds input rate: 0 bits/sec, 0 packets/sec
Last 300 seconds output rate: 0 bits/sec, 0 packets/sec
Input: 486833280327643 bytes, 720675974914 packets
Output: 66656626810850 bytes, 400094354049 packets
Input:
CRC: 688 packets, Symbol: 200 packets
Overrun: 0 packets
InRangeLength: 0 packets
LongPacket: 0 packets, Jabber: 0 packets,
Fragment: 3 packets, Undersized Frame: 0 packets
RxPause: 0 packets
Output:
System: 0 packets, Overruns: 0 packets
TxPause: 0 packets
Unknown Vlan: 0 packets
Procedure
Step 1 Run the system-view command on Router A to enter the system view.
Step 2 Run the interface interface-type interface-number command on Router A to enter the interface
view.
Step 3 Run the shutdown command on Router A. Packets are transmitted from Router A through
Router C to Router B instead of from Router A to Router B. Then, services are running normally.
After the preceding operations, the fault is rectified. Then, check the link between Router A and
Router B.
----End
Summary
When route flapping occurs, you need to check the route type, and then check whether the
relevant protocols flap. If the protocols do not flap, you need to check whether IP address
collision occurs.
1.2.14 CE Cannot Access Some Web Servers Due to the MTU

Configuration
Fault Symptom
On the network shown in Figure 1-15, BGP/MPLS VPN is configured on the PEs. CE1, Web
server A, and Web server B are in the same VPN. PE3 and Web server A are connected through
a firewall. After the configuration is complete, the CE cannot access some Web servers.
Issue 02 (2011-09-10)

37

Figure 1-15 Networking diagram of the CE failing to access some Web servers
CE2
Web Server B
PE2
PE1
Switch
PE3
Firewall
Web Server A
CE3
CE1
Fault Analysis
1.
Run the display bgp vpnv4 all peer command on PE1 and PE2. It is found that the BGP
peer relationships are set up between the PEs and between the PE and CE and are in the
Established state.
2.
Run the ping -vpn-instance vpn-instance-name command on PE1, PE2, and PE3. The
accessed CEs can be pinged successfully from the PEs.
3.
Run the display current-configuration configuration vpn-instance vpn-instance-name

command on PE1, PE2, and PE3 to view the configurations of the VPN instances. It is
found that the VPN instances on the PEs are configured correctly and the import VPN target
on one PE matches the export VPN target on another PE.
4.
Capture packets on an interface of the PE. It is found that the length of an IP packet sent
from the Web server is 1496 bytes and the IP packet cannot be fragmented. The length of
the packet becomes 1504 bytes (1496+8(length of double MPLS labels)) after the packet
enters the MPLS network.
5.
Run the display mpls interface command on PE1, PE2, and the P to view the MTU of
MPLS packets on an interface. It is found that the MTU value for MPLS packets on the P
is 1500. As the MPLS packets are longer than 1504 bytes, they are discarded on the PE or
P.
Procedure
Step 1 Run the system-view command on the P to enter the system view.
Step 2 Run the interface interface-type interface-number command to enter the interface view of the
interface connecting the P to the PE.
Step 3 Run the mtu mtu command to reconfigure the MTU value on the interface.
Issue 02 (2011-09-10)

38

Step 4 Run the mpls mtu 1600 command to re-configure the MTU value for MPLS packets on the
interface.
NOTE
The relationship between the MPLS MTU on an interface and the interface MTU is as follows:
l If the MPLS MTU is not configured on the interface, the MTU on the interface is used.
l If the MTU of the MPLS packets is set, the MPLS MTU is compared with the MTU on the interface
and the smaller one is adopted.
Step 5 Run the restart command to restart the current interface.

After the preceding operations, it is found that CE1 can access Web server A and Web server
B. The fault is rectified.
----End
Summary
The cause of this troubleshooting case is as follows:
l
The packet sent from the Web server cannot be fragmented, and the packet length exceeds
the MPLS MTU on the P after two MPLS labels are added. As a result, the packet is
discarded on the P.
The Firewall prevents ICMP packets, causing the path MTU discovery mechanism to be
invalid.
The basic principle of the path MTU discovery mechanism is as follows:

1.
The source initially adopts the MTU on the fist hop interface as the MTU of the path to the
destination and sets the value of the Don't Fragment (DF) bit in all IP packets sent to the
destination to 1.
2.
When a device along the path receives the packet and forwards the packet on an outbound
interface, the device discovers that the packet length exceeds the MTU on the outbound
interface and the value of the DF bit is 1. In this case, the device discards the packet and
responds with an ICMP unreachable packet (type=3, code=4, fragment needed but don'tfragment bit set) to the source.
3.
After receiving the ICMP unreachable packet, the source decreases the path MTU value
and re-sends the IP packet.
This problem is caused by an incorrect MTU value. To resolve the problem, re-configure the
MTU.
1.2.15 The RR Fails to Reflect VPN Routes

Fault Symptom
On the network shown in Figure 1-16, an Route Reflector (RR) is configured to optimize BGP/
MPLS VPN services. CE1 and CE2 are in the same VPN. After the configuration is complete,
it is found that the RR can learn a VPNv4 route advertised by PE1 but PE2 fails to learn this
route.
Issue 02 (2011-09-10)

39

Figure 1-16 Networking diagram of the RR failing to reflect VPN routes
Route Reflector
PE1
(Client1)
PE2
(Client2)
CE1
CE2
Fault Analysis
1.
Run the display current-configuration configuration bgp command on the RR and PEs.
It is found that route reflection relationships are correctly set up between the RR and two
PEs.
2.
Run the display bgp vpnv4 all peer command on the RR. It is found that the IBGP peer
relationships between the RR and the PEs are in the Established state ( BGP current state:
Established, Up for 00:21:15).
3.
Run the display ip extcommunity-filter command on the RR to view information about

the extended community attribute filter.
Extended Community filter Number 1
deny rt : 100:1
permit rt : 200:1
The output of the display ip extcommunity-filter command indicates that the routes with
the RT being 100:1 are filtered out.
4.
Run the display ip vpn-instance verbose command on PE1 to view detailed information
about all VPN instances.
Total VPN-Instances configured : 1
VPN-Instance Name and ID : a, 1
Create date : 2010/06/23 20:18:40 UTC+08:00 DST
Up time : 0 days, 00 hours, 02 minutes and 27 seconds
Route Distinguisher : 1:1
Export VPN Targets : 100:1
Import VPN Targets : 111:1
Label Policy : label per route
Import Route Policy : p1
Export Route Policy : p2
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
The VPN QoS configuration information : based on VPN
CIR: 10000000 PIR: 10000000 QoS-profile name: profile1
Tunnel Policy : tnlpolicy1
Description : This is a VPN for company1.
Issue 02 (2011-09-10)

40

Maximum Routes Limit : 100

Log Interval : 5
Interfaces : GigabitEthernet1/0/0
The output of the display ip vpn-instance verbose command indicates that the packets
with the Export VPN Targets field being 100:1 are filtered out on the RR. As a result, the
RR does not reflect routes to PE2.
Procedure
Step 1 Run the system-view command on the RR to enter the system view.
Step 2 Run the ip extcommunity-filter 1 permit rt 100:1 command on the RR to make the Export RT
on PE1 and the RT of the extended community filter on the RR the same.
Step 3 Run the bgp as-number command on the RR to enter the BGP view.
Step 4 Run the ipv4-family vpnv4 command on the RR to enter the BGP-VPNv4 address family view.
Step 5 Run the undo rr-filter command on the RR to delete the original reflection policy of the RR.
Step 6 Run the rr-filter 1 command on the RR to specify a new reflection policy for the RR.
After the preceding operations, PE2 can learn the VPNv4 routes advertised by PE1. The fault is
rectified.
----End
Summary
When configuring an RR, ensure that the Import VPN target and Export VPN target match the
RTs on PE1 and PE2.
To minimize the impact of incorrect configurations, you can run the undo policy vpn-target
command to permit all VPNv4 routes.
1.2.16 CE1 Cannot Register with CE2 Because the Maximum

Number of Routes Exceed the Upper Threshold
Fault Symptom
On the network shown in Figure 1-17, the PE is configured with BGP/MPLS VPN services,
which are classified into signaling VPN services and media VPN services. CE1 is an Access
Gateway (AG) device; CE2 is a Softswitch device (Soft3000); CE1 and CE2 are in the same
VPN. After the configuration is complete, it is found that CE1 cannot register with CE2.
Issue 02 (2011-09-10)

41

Figure 1-17 Networking diagram of an AG device failing to register with a Softswitch device
PE1
CE1
PE2
CE2
Fault Analysis
1.
Run the display bgp vpnv4 all peer command on PE1 and PE2. It is found that the BGP
peer relationships between the PEs and between the PEs and CEs are in the Established
state.
2.
Run the ping -vpn-instance vpn-instance-name command on PE1 and PE2. It is found that
the PEs can ping the corresponding CEs successfully.
3.
Run the display ip routing-table vpn-instance vpn-instance-name command on PE1 and

PE2. It is found that PE1 and PE2 have VPN instance routes that are destined for each other.
4.
Run the display bgp vpnv4 all routing-table 10.1.1.1 command on PE1 to view the
information about the BGP routes to the network segment 10.1.1.1/24. It is found that there
are two routes in the signaling VPN and no route in the VPN instance.
From: 11.1.1.1 (11.1.1.1)
Ext-Community: <65029 : 2995>
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid,
internal, best, pre 255
Originator: 12.1.1.1
Cluster list: 11.1.1.1
From: 11.1.1.2 (11.1.1.2)
Ext-Community: <65029 : 2995>
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid,
internal, pre 255
Originator: 12.1.1.1
Cluster list: 11.1.1.2
Issue 02 (2011-09-10)

42

5.
Run the display current-configuration configuration vpn-instance vpn-instance-name

command on PE1 to view the configurations of the VPN instance. It is found that route
restriction is configured in the signaling VPN of PE1.
ip vpn-instance ngn-signal
apply-label per-instance
routing-table limit 100 80
6.
Run the display ip routing-table vpn-instance vpn-instance-name statistics command on

PE1 to view the statistics on the routes of the VPN instance. It is found that the number of
the routes of the VPN instance exceeds the threshold of route restriction.
Proto
DIRECT
STATIC
RIP
OSPF
IS-IS
BGP
Total
total
routes
10
1
0
8
0
81
100
original
routes
10
1
0
8
0
81
100
active
routes
10
1
0
6
0
34
51
original
active
10
1
0
6
0
34
51
added
routes
10
2
0
13
0
0
25
deleted
routes
0
1
0
5
0
0
6
freed
routes
0
1
0
5
0
0
6
The number of actual VPN instance routes exceeds the threshold of route restriction.
Therefore, new VPN instance routes from PE2 cannot be added to the VPN routing table
on PE1. As a result, the AG cannot register with the softswitch.
Procedure
Step 1 Run the system-view command on PE1 to enter the system view.
Step 2 Run the ip vpn-instance vpn-instance-name command on PE1 to enter the VPN instance view.
Step 3 Run the routing-table limit 200 80 command on PE1 to re-configure the maximum number of
routes supported by the current VPN instance.
After the preceding operations, CE2 can be pinged successfully from CE1, and CE1 can register
with CE2. The fault is rectified.
----End
Summary
If the maximum number of routes supported by the VPN instance is configured, you need to
check whether the actual routes in an VPN instance exceeds the configured upper threshold.
1.2.17 Users Attached to a CE Cannot Access the Internet After BGP/

MPLS IP VPN Services Are Deployed
Fault Symptom
As shown in Figure 1-18, a PE is connected to an SPE and the SPE is connected to a UPE to
form a layered network. Each PE is deployed with multiple VPN instances, each of which
configured with multiple export RTs and import RTs. The PE is configured with logical
interfaces, each of which is bound to a VPN instance and connected to the firewall. The SPE
delivers default routes of each VPN instance to the UPE to guide the forwarding of traffic sent
from the CE to the SPE. After the configurations, users attached to the CE cannot access the
Internet.
Issue 02 (2011-09-10)

43

Figure 1-18 Networking diagram of the case where users attached to a CE cannot access the
Internet
PE
Firewall
Internet
SPE
UPE
CE
Fault Analysis
1.
Run the display ip routing-table vpn-instance command on the UPE. Each VPN instance
has learned two default routes.
2.
Run the display current-configuration configuration vpn-instance command on the

UPE to view the configurations of VPN instances. Each VPN instance has been configured
with multiple export RTs and import RTs.
3.
Run the display current-configuration configuration vpn-instance command on the SPE

to view the configurations of VPN instances. RTs of two VPN instances are the same, and
thus the default routes learned from two VPN instances are advertised to the UPE through
the same export RT. In addition, the export RT matches multiple import RTs of one VPN
instance on the UPE. As a result, the UPE learns multiple default routes from the same
VPN instance. In this case, the traffic received by the SPE from the CE has multiple BGP
next hops, and thus status entries cannot be created on the firewall. Consequently, users
attached to the CE cannot access the Internet.
Procedure
Step 1 Run the system-view command on the UPE to enter the system view.
Step 2 Run the ip vpn-instance vpn-instance-name command on the UPE to enter the VPN instance
view.
Step 3 Run the vpn-target vpn-target &<1-8> import-extcommunity command on the UPE to
configure VPN-target extended community attribute for the VPN instance.
Issue 02 (2011-09-10)

44

Ensure that each VPN instance on the UPE is configured with only one import RT so that only
one default route can be learned. After the preceding operations, users attached to the CE can
access the Internet. The fault is rectified.
----End
Summary
Different from PEs or SPEs, a UPE on a layered network only use default routes to guide
upstream traffic. Therefore, the UPE can be configured with multiple export RTs as required
but should be configured with only one import RT. Otherwise, the fault occurs.
1.2.18 VPNv4 Routes on a PE Cannot Take Effect

Fault Symptom
On the network shown in Figure 1-19, three PEs are configured with BGP/MPLS VPN services.
Traffic from a CE is balanced between PE1 and PE2. PE2 is connected to PE1, and PE1 is
connected to PE3 over a Metropolitan Area Network (MAN). After the configurations, PE1
learns the route to the network segment 10.1.2.0, and the BGP VPNv4 routing table of PE2
contains this route entry, but the VPN instance routing table of PE2 does not.
Figure 1-19 Networking diagram of the case where VPNv4 routes on a PE cannot take effect
PE3
10.1.2.1/24
MAN
10.1.1.1/24 10.1.1.2/24
PE1
PE2
CE
Issue 02 (2011-09-10)

45

Fault Analysis
1.
Run the display bgp vpnv4 all routing-table command on PE2 to view BGP VPNv4
routes. PE2 has learned the route to the network segment 10.1.2.0 but the route is not
optimal.
Network
*>
1.1.1.0/24
export
*
1.1.1.2/32
export
*i
10.1.2.0/24
2.
NextHop
1.1.1.1
MED
0
1.1.1.1
10.1.1.1
100
LocPrf
PrefVal Community
0
no0
0
nono-export
Run the display ip routing-table vpn-instance vpn1 10.1.2.0 verbose command on PE2
to view the routing table of the VPN instance.
Routing Table :
vpn1
Summary Count :
1
Destination:
10.1.2.0/24
Protocol:
0
Preference:
0
NextHop:
NULL0
RelayNextHop:
10.1.1.1
Label:
0x0
BGP
Process ID:
255
Cost:
10.1.1.1
Interface:
0.0.0.0
Neighbour:
109568
Tunnel ID:
SecTunnel ID:
0x0
BkNextHop: 0.0.0.0
BkInterface:
BkLabel: NULL
0x0
Tunnel ID:
SecTunnel ID:
0x0
State: Inactive Adv WaitQ
Age: 22h35m37s
The preceding routing information shows that the outbound interface of the next hop is
Null0, and thus packets are discarded.
If VPNv4 routes are used to forward traffic, LSP labels of the public network will be added
to the routes. Before adding a VPNv4 route to the routing table of a VPN instance, the
system checks whether the route contains a corresponding LSP label of the public network.
If no such LSP label corresponding to the VPNv4 route exists, the route will not be added
to the routing table.
3.
Run the display mpls lsp command on PE2. No route to 10.1.1.1 is displayed, indicating
that no neighbor relationship has been established between PE1 and PE2.
Procedure
Step 2 Run the mpls command to enable MPLS and enter the MPLS view.
Step 4 Run the mpls ldp command to enable LDP globally and enter the MPLS LDP view.
Issue 02 (2011-09-10)

46

Step 5 (Optional) Run the lsr-id lsr-id command to set the LSR ID for the LDP instance.
Step 7 Run the interface interface-type interface-number command to enter the view of the interface
connecting PE1 to the peer.
Step 8 Run the mpls command to enable MPLS on this interface.
Step 9 Run the mpls ldp command to enable LDP on this interface.
Perform all the preceding operations on PE2. After the operations, PE1 will have learned the
route to the network segment 10.1.2.0 and both the BGP VPNv4 routing table of PE2 and the
routing table of the VPN instance have routes to the network segment 10.1.2.0. The fault is
rectified.
----End
Summary
If VPNv4 routes are used to forward traffic, LSP labels of the public network will be added to
the routes. Before adding a VPNv4 route to the routing table of a VPN instance, the system
checks whether the route contains a corresponding LSP label of the public network. If there is
no such LSP label corresponding to the VPNv4 route, the route will not be added to the routing
table.
1.2.19 MPLS VPN Convergence Is Slow

Fault Symptom
The protocols of IS-IS and BGP and MPLS VPN services are configured on six PE devices. All
the PEs use the same RD; PE1 and PE2 serve as RRs. The router ID of PE1 is smaller than that
of PE2; the router ID of PE3 is smaller than that of PE4; the router ID of PE5 is smaller than
that of PE6. The two CEs belong to the same VPN.
Figure 1-20 Typical Network Diagram for MPLS VPN
PE1
PE3
PE2
PE4 PE5
CE1
Issue 02 (2011-09-10)

PE6
CE2
47

After PE3 is restarted, PE5 and PE6 have to wait for 2 minutes before learning the route to the
segment where CE1 resides.
Fault Analysis
PE5 and PE6 learn two equal-cost MPLS VPN routes to CE1 through PE3 and PE4. IGP selects
the route passing through PE3 as the optimal route to CE1 because the router ID of PE3 is smaller
than that of PE4.
After PE3 is restarted, the two RRs (PE1 and PE2) forward another route to the segment where
CE1 resides to PE5 and PE6 when confirming that they cannot establish BGP neighbor
relationships with PE3. After IGP convergence is complete, MPLS VPN convergence starts.
MPLS VPN convergence is rather slow because its time depends on the number of routing entries
in the routing tables of the routers. Usually, MPLS VPN convergence takes about 2 minutes.
Procedure
Step 2 Run the ip vpn-instance vpn-access command to enter the view of the corresponding VPN
instance.
Step 3 Run the route-distinguisher 22:1 command to change the RD for the VPN instance on PE3 to
be different from that on the other PEs.
After the configuration, PE5 and PE6 learn two MPLS VPN routes with different next hops to
CE1 through PE3 and PE4. One of the routes is active, and the other is inactive.
When PE3 is restarted again, the active route is removed from the MPLS VPN routing table. In
this case, the inactive route quickly switches to be an active route without waiting for the finding
of a reachable IGP route. Therefore, the convergence speed is rather quick. The fault is rectified.
----End
Summary
MPLS VPN convergence may become slow due to slow IGP convergence. In this case, you can
set different RDs on PEs to configure two MPLS VPN routes for backup or alternatively
configure VPN FRR to rectify the fault.
1.2.20 One-way Audio Occurs Between the CEs Because the vpntarget import-extcommunity Command Is Not Configured
Fault Symptom
On the network shown in Figure 1-21, each CE (UMG) is dual-homed to two PEs. The PEs on
the network belong to different planes:
l
PE1 and PE2 belong to plane A.
PE3 and PE4 belong to plane B.
In normal situations, the traffic between the CEs, which are in the same VPN, is transmitted on
plane B.
Issue 02 (2011-09-10)

48

Different VPN instances are configured on the PEs to separately carry signaling traffic and media
traffic between the CEs.
When the configuration is complete, call tests are conducted. In the first try, one-way audio
occurs: Voices from Phone1 can be heard on Phone2, but voices from Phone2 cannot be heard
on Phone1. In the second try, voices can be heard on both phones.
Figure 1-21 Networking diagram of one-way audio between the CEs
CE 1
(UMG1)
Network
PE 1
PE 2
CE 2
(UMG2)
Plane A
Plane B
PE 3
PE 4
Network
Phone1
Phone2
Fault Analysis
1.
Calls can be successfully set up between the CEs, it indicates that the problem is not on the
VPN instance bearing signaling traffic but on the VPN instance bearing media traffic
between the CEs.
2.
Run the display current-configuration configuration vpn-instance command on PE3 to

check the configurations of the VPN instance bearing media traffic. You can find that the
vpn-target import-extcommunity command is not configured.
As a result, PE3 does not receive the VPN route that is used to transmit media traffic from
PE4. So, the media traffic from CE2 is not sent to CE1. That is the reason why there is oneway audio from Phone1 to Phone2 in the first call try.
On the CE side, media traffic is sent to both the PEs to which the CE is dual-homed. In the
first call, media traffic is transmitted on plane B. Once the transmission on plane B has
problems (that is, one CE does not receive the traffic from the other CE), media traffic
enters plane A for transmission in the next dial-up. That is the reason why voices can be
heard on both Phone1 and Phone2 in the second call try.
Procedure
Step 1 Run the system-view command to enter the system view on PE3.
Step 2 Run the ip vpn-instance vpn-instance-name command to enter the view of the VPN instance
that carries the media traffic between the CEs.
Issue 02 (2011-09-10)

49

Step 3 Run the vpn-target vpn-target &<1-8> import-extcommunity command to configure VPNtarget of the extended community attribute to receive the routing information that carries the
specified VPN-target.
When the configuration is complete, the audio communication between Phone1 and Phone2 is
normal in call tests.
----End
Summary
In the application of BGP/MPLS VPN on the Next Generation Network (NGN), different VPN
instances are used to separately bear signaling traffic and media traffic. If a fault occurs, first
determine based on the fault symptom whether it is due to the VPN instance bearing signaling
traffic or the VPN instance bearing media traffic.
In addition, VPN-target has no default value. Therefore, you need to manually configure VPNtarget when creating a VPN instance. You can specify "both", "export", or "import" to associate
a VPN instance with one or more VPN-targets. By default, "both" is used.
1.2.21 PEs Fail to Exchange Private Network Routes Because the

Mask Set for the Loopback Interface Is Not a 32-bit Mask
Fault Symptom
On the network shown in Figure 1-22, BGP/MPLS IP VPN services and OSPF are configured
on the two PEs and the P. A loopback interface is created on each PE and bound to a VPN
instance named vpn1. The IP address of the loopback interface on PE1 is 1.1.1.1; the IP address
of the loopback interface on PE2 is 1.1.1.2.
When the configuration is complete, the two PEs cannot exchange private network routes, and
the ping between them fails.
Figure 1-22 Networking diagram for the failure in exchanging private network routes between
PEs
Loopback1
PE 1
Loopback1
GE1/0/1
GE1/0/2
GE1/0/2
GE1/0/1
PE 2
Fault Analysis
1.
Issue 02 (2011-09-10)
Run the display ospf peer command on each PE, and you can view that the neighbor status
is Full. Run the display ip routing-table command on each PE, and you can view that each
PE has learned the route to Loopback1 on the peer PE.
50

2.
Run the display mpls ldp session command on the P. You can view that the LDP peer
relationships between the P and PEs are established.
3.
Run the display mpls lsp command on both PEs to check label allocation. You can find
that the PEs have LSPs to each other.
4.
Run the display this command in the BGP-VPNv4 address family view on each PE. You
can find that the peer ipv4-address enable command has been configured. Run the display
bgp vpnv4 all peer command on each PE. You can find that the BGP peer relationships
are established between the PEs and between the PE and CE.
5.
Run the display ip routing-table vpn-instance vpn1 command on each PE to check the
VPN routing table. A route, 1.1.1.0/24 direct, with Loopback1 being the outbound interface,
is found in the routing table. The mask of the route is a 24-bit value rather than a 32-bit
value.
Destination/Mask
1.1.1.0/24
6.
Proto
Direct 0
Pre
Cost
Flags NextHop
D
1.1.1.1
Interface
LoopBack1
Run the display ip interface brief command on each PE. You can find that a 24-bit mask
(not a 32-bit mask) is configured for the IP address of Loopback1.
Interface
LoopBack1
IP Address/Mask
1.1.1.1/24
Physical
up
Protocol
up(s)
In this manner, the IP addresses of loopback interfaces on the two PEs belong to the same
network segment (1.1.1.0/24). In fact, the PEs have learned private network routes from
each other. On each PE, the learned private network route and local Loopback1, however,
belong to the same network segment. Then, there are two routes to Loopback1 on the peer
PE: One is a direct route; the other is a BGP route. In this case, the PE places the direct
route in its routing table, and there are no private network routes in the VPN routing table.
As a result, Loopback1 on the peer PE fails to be pinged.
Procedure
Step 2 Run the interface loopback1 command to enter the view of Loopback1 bound to the VPN
instance.
Step 3 Run the ip address ip-address { mask | mask-length } command to configure an IP address with
a 32-bit mask on each PE.
When the configuration is complete, the PEs can successfully ping Loopback1 on each other,
and the fault is rectified.
----End
Summary
When configuring BGP/MPLS IP VPN services, ensure that the IP addresses of the interfaces
bound to the same VPN instance but residing on different PEs belong to different network
segments.
Issue 02 (2011-09-10)

51

1.2.22 Some MPLS VPN Services on a Device Become Abnormal

After the Service Cutover
Fault Symptom
On the carrier's MAN shown in Figure 1-23, all devices except Router A are non-Huawei
devices. Router C and Router D (two non-Huawei devices) function as MAN's egress core
routers at Site A and Site B respectively. The total outbound bandwidth of the egress device of
the MAN is 3 x 2.5 GB. The bandwidth of the link from Router C at Site A to Router A on the
backbone network is 1 x 2.5 GB, and the bandwidth of the link from Router D at Site B to
Router B on the backbone network is 2 x 2.5 GB. Outbound bandwidths of Router E to
Router A and Router G to Router B are both 2 x 10 GB.
Figure 1-23 Networking of the MAN before service cutover
RouterE
RouterF
RouterG
RouterH
RouterB
RouterA
Site A
Site B
Backbone network
MAN
RouterD
RouterC
10G
2.5G
The carrier optimizes the MAN and the backbone network to better facilitate the growing service
requirements. As shown in Figure 1-24, backbone nodes Router A and Router B function as
MAN's egress core routers and directly establish EBGP peer relationships with Router E and
Router G on the backbone network respectively. Router C and Router D (previously core
routers on the MAN) are removed from the networking for other purpose. The MAN continues
Issue 02 (2011-09-10)

52

to use the private AS number. The IBGP peer relationship is established between Router A and
Router B (two core routers on the MAN). The SR and the BRAS that are previously attached to
Router C and Router D respectively are now attached to Router A and Router B respectively.
Figure 1-24 Networking of the MAN after service cutover
RouterE
RouterF
RouterG
RouterH
Backbone network
MAN
RouterB
Site A
Site B
RouterA
10G
2.5G
As shown in Figure 1-25, after service cutover, service tests are performed on Router A. It is
found that MPLS VPN services of some users in the same VPN instance work normally but
some MPLS VPN services on the BRAS become abnormal.
Issue 02 (2011-09-10)

53

Figure 1-25 Networking of the MAN during service cutover
RouterE
RouterF
RouterG
RouterH
RouterB
Site B
Backbone network
MAN
RouterD
Site A
RouterA
10G
2.5G
Fault Analysis
1.
Run the display current-configuration configuration command on Router A to check

current configurations, and you can find that current configurations are correct.
2.
Check configurations about the interface MTU and the BRAS on Router A, and you can
find that these configurations are correct.
3.
Run the ping lsp -a source-ip command (source-ip specifies the loopback interface address
of Router A) on Router A to ping the loopback interface address of the BRAS. The ping
succeeds, indicating that packet forwarding between Router A and the BRAS is normal.
4.
Run the ping lsp -a source-ip command (source-ip specifies the loopback interface address
of the BRAS) on the BRAS to ping the loopback interface address of the inaccessible PE
in the VPN. It is found that the ping fails.
5.
Run the display mpls ldp peer command on the BRAS to check information about LDP
peers. You can find that the address used to establish the LDP peer relationship between
Router D and the BRAS is the address of Loopback1 rather than Loopback0. Because
customers have special requirements, the address of Loopback1 on Router C is set to the
same as the address of Loopback1 on Router A.
Issue 02 (2011-09-10)

54

6.
Run the display mpls ldp peer command on Router A to check information about LDP
peers. You can find that the address used to establish the LDP peer relationship between
Router D and Router A is also the address of Loopback1 rather than Loopback0.
7.
Run the display current-configuration configuration command on Router D to check

current configurations. You can find that the address of Loopback1 is mistakenly used to
establish the LDP peer relationship on Router D. The fact is that the address of Loopback0
should be used to establish the LDP peer relationship on Router D. As a result, some MPLS
VPN services forwarded by Router D cannot be accessed. Before service cutover is
implemented on Router A, traffic is transmitted through previous core routers on the MAN.
During service cutover, the traffic is switched to Router D. After service cutover, the traffic
is not switched back to Router A, thus causing the fault.
Procedure
Step 1 Set the address of Loopback0 as the address used to establish the LDP peer relationship on
Router D.
----End
Summary
The major cause of the fault is that MPLS LSP forwarding is abnormal. If the fault occurs, run
the ping lsp commands with source addresses on the PEs to ping each other.
Issue 02 (2011-09-10)

55

2 VPLS Troubleshooting
VPLS Troubleshooting
About This Chapter

This chapter describes common causes of VPLS faults and provides the corresponding
2.1 VSI of Martini VPLS Cannot Go Up
This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting
procedure for the fault that the VSI of Martini VPLS cannot go Up.
2.2 VSI of Kompella VPLS Cannot Go Up
procedure for the fault that the VSI of Kompella VPLS cannot go Up.
2.3 VSI Goes Up Only on One End
procedure for the fault that the VSI goes Up only on one end.
2.4 A Huawei Device Cannot Establish a PW with Another Vendor's Device on a Kompella
VPLS Network
procedure for the fault that a Huawei device cannot establish a PW with another vendor's device
on a Kompella VPLS network.
Issue 02 (2011-09-10)

56

2.1 VSI of Martini VPLS Cannot Go Up

procedure for the fault that the VSI of Martini VPLS cannot go Up.
2.1.1 Common Causes

This fault is commonly caused by one of the following:
l
Encapsulation types of both ends are different.
MTUs of both ends are different.
VSI IDs of both ends are different.
LDP sessions are not in the Up state.
The tunnel policy for selecting a TE tunnel as the public network tunnel is incorrectly
configured.
The local or remote end of the tunnel does not go Up.
The local or remote AC interface does not go Up.

After Martini VPLS is configured, the VSI cannot go Up.
Issue 02 (2011-09-10)

57

Figure 2-1 Troubleshooting flowchart for the fault that the VSI of Martini VPLS cannot go Up
The Martini VSI
is Down
Are
encapsulation types
of both ends the
same?
No
Yes
Are MTUs
of both ends the
same?
No
No
No
Yes
Yes
Is fault rectified?
End
Yes
Is fault rectified?
End
No
No
Is fault rectified?
Yes
End
No
Yes
Are AC
interfaces of both ends
Up?
End
No
Yes
Tunnel is
Selected?
Yes
Is fault rectified?
No
Yes
Is the LDP session

Up?
End
No
Yes
Are the
VSI IDs of both ends
the same?
Yes
Is fault rectified?
No
Is fault rectified?
Yes
End
No
Seek technical
support
Issue 02 (2011-09-10)

58


NOTE
Procedure
Step 1 Check that the encapsulation types of both ends are the same.
<HUAWEI> display vsi name tt
Vsi
Mem
PW
Mac
Encap
Mtu
Vsi
Name
Disc
Type Learn
Type
Value State
-------------------------------------------------------------------------tt
static ldp unqualify vlan
1500
up
l If the encapsulation types of both ends are different, run the encapsulation { ethernet |
vlan } command in the VSI view to change the encapsulation type of either end, ensuring
that the encapsulation types of both ends are the same.
l If the encapsulation types of both ends are the same, go to Step 2.
NOTE
The same encapsulation type on both ends is one of the prerequisites for the VSI to go Up.
Step 2 Check that MTUs of both ends are the same.

Vsi
Mem
PW
Mac
Encap
Mtu
Vsi
Name
Disc
Type Learn
Type
Value State
-------------------------------------------------------------------------tt
static ldp unqualify vlan
1500
up
l If the MTUs of both ends are different, run the mtu mtu-value command in the VSI view to
change the MTU of either end, ensuring that the MTUs of both ends are the same.
l If the MTUs of both ends are the same, go to Step 3.
NOTE
The same MTU on both ends is one of the prerequisites for the VSI to go Up.
Step 3 Check that the VSI IDs or negotiation-VC-IDs of both ends are the same.
<HUAWEI> display vsi name tt verbose
***VSI Name
Administrator VSI
Isolate Spoken
VSI Index
PW Signaling
Member Discovery Style
PW MAC Learn Style
Encapsulation Type
MTU
Diffserv Mode
Service Class
Color
DomainId
Domain Name
Tunnel Policy Name
Ignore AcState
Create Time
VSI State
VSI ID
*Peer Router ID
Issue 02 (2011-09-10)
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
tt
no
disable
3
ldp
static
unqualify
vlan
1500
uniform
--255
p1
disable
2 days, 2 hours, 47 minutes, 40 seconds
up
: 101
: 2.2.2.2

59

VC Label
Peer Type
Session
Tunnel ID
Broadcast Tunnel ID
CKey
NKey
StpEnable
PwIndex
:
:
:
:
:
:
:
:
:
187393
dynamic
up
0xc0060401
0xc0060401
6
5
0
0
Interface Name
State
Last Up Time
Total Up Time
:
:
:
:
GigabitEthernet8/0/0.12
up
2010/02/05 06:36:57
l If the VSI IDs or negotiation-VC-IDs are different for both ends, run the pwsignal ldp
command in the VSI-LDP view to modify the VSI ID of either end, or run the peer peeraddress negotiation-VC-ID vc-id command in the VSI-LDP view to modify the negotiationVC-ID of either end, ensuring that the VSI IDs or negotiation-VC-IDs of both ends are the
same.
l If the VSI IDs or negotiation-VC-IDs of both ends are the same, go to Step 4.
NOTE
The same VSI ID or negotiation-VC-ID on both ends is one of the prerequisites for the VSI to go Up.
Step 4 Check that the LDP session between both ends is Up.
Run the display vsi name vsi-name verbose command to check whether the Session field is
displayed as Up.
<HUAWEI> display vsi name tt verbose
***VSI Name
Administrator VSI
Isolate Spoken
VSI Index
PW Signaling
PW MAC Learn Style
Encapsulation Type
MTU
Diffserv Mode
Service Class
Color
DomainId
Domain Name
Tunnel Policy Name
Ignore AcState
Create Time
VSI State
VSI ID
*Peer Router ID
VC Label
Peer Type
Session
Tunnel ID
Broadcast Tunnel ID
CKey
NKey
StpEnable
PwIndex
Interface Name
State
Last Up Time
Total Up Time
Issue 02 (2011-09-10)
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
tt
no
disable
3
ldp
static
unqualify
vlan
1500
uniform
--255
:
:
:
:
:
:
:
:
:
:
:
101
2.2.2.2
187393
dynamic
up
0xc0060401
0xc0060401
6
5
0
0
:
:
:
:
up
2010/02/05 06:36:57
p1
disable
up

60

l If the LDP session between both ends does not go Up, refer to the section "LDP Session Goes
Down" to locate the fault and ensure that the LDP session goes Up.
l If the LDP session between both ends is Up, go to Step 5.
NOTE
The Up status of the LDP session is one of the prerequisites for both ends to perform the L2VPN negotiation.
Step 5 Check whether the VSI has selected a tunnel.

Run the display vsi name vsi-name verbose command to check the following:
l Check whether the Tunnel ID field is displayed as 0x0. If so, it indicates that the VSI does
not select a tunnel.
l Check the Tunnel Policy Name field. If this field is not displayed, it indicates that the VSI
selects an LDP LSP or no tunnel policy is configured for the VSI. If the VSI selects an MPLSTE tunnel, a tunnel policy must be configured. The value of the Tunnel Policy Name field
indicates the tunnel policy of the VSI. You can view details of the tunnel policy by running
the display this command in the corresponding tunnel policy view.
#
tunnel-policy p1
#
NOTE
If the tunnel binding destination dest-ip-address te { tunnel interface-number } command is configured

in the tunnel policy view, you also need to configure the mpls te reserved-for-binding command in the
tunnel interface view.
If the tunnel between both ends is not Up, refer to the session "LSP Goes Down" or "TE Tunnel
Goes Down" to locate the fault and ensure that the tunnel goes Up. If the tunnel between both
ends is Up and the TE interfaces are correctly configured, go to Step 6.
NOTE
The Up status of the tunnel is one of the prerequisites for the VSI to go Up.
Step 6 Check that the AC interfaces of both ends are in the Up state.
Run the display vsi name vsi-name verbose command on both ends to check whether the
interfaces corresponding to the Interface Name field are in the Up state.
l If not, refer to the section "Physical Interconnection & Interface Type" to locate the fault and
ensure that the AC interfaces go Up.
l If the AC interfaces on both ends are Up, go to Step 7.
NOTE
The Up status of AC interfaces on both ends is one of the prerequisites for the VSI to go Up.
----End

Issue 02 (2011-09-10)

61

Relevant Alarms
None.
Relevant Logs
None.
2.2 VSI of Kompella VPLS Cannot Go Up

procedure for the fault that the VSI of Kompella VPLS cannot go Up.
2.2.1 Common Causes

l
Encapsulation types of both ends are different.
MTUs of both ends are different.
BGP is not in the Established state.
The tunnel policy for selecting a TE tunnel as the public network tunnel is incorrectly
configured.
The site-id of the local end is greater than the sum of the range and offset of the remote
end.
The local or remote AC interface does not go Up.

After Kompella VPLS is configured, the VSI cannot go Up.
Issue 02 (2011-09-10)

62

Figure 2-2 Troubleshooting flowchart for the fault that the VSI of Kompella VPLS cannot go
Up
The Kompell VSI is
Down
Are
encapsulation types
and MTUs of both ends
the same?
No
Yes
Are site
IDs of both ends the
same?
No
End
No
No
Is fault rectified?
Yes
End
No
No
Yes
Is the
site-id of either end
smaller than the sum of the
range and offset of the
other end?
End
Yes
Is fault rectified?
Yes
Tunnel is
Selected?
Yes
No
Yes
Is the BGP session

Established?
Is fault rectified?
Is fault rectified?
Yes
End
No
No
Yes
End
Is fault rectified?
No
Yes
Are AC
interfaces of both ends
Up?
Yes
No
Is fault rectified?
Yes
End
No
Seek technical
support
Issue 02 (2011-09-10)

63


NOTE
Procedure
Step 1 Check that encapsulation types and MTUs of both ends are the same.
<HUAWEI> display vsi name tt2
Vsi
Mem
PW
Mac
Encap
Mtu
Vsi
Name
Disc
Type Learn
Type
Value State
-------------------------------------------------------------------------tt2
auto
bgp unqualify vlan
1500
up
l If the encapsulation types or MTUs of both ends are different, run the encapsulation
{ ethernet | vlan } command to change the encapsulation type of either end, or run the
mtu mtu command to change the MTU of either end, ensuring that the encapsulation types
or MTUs of both ends are the same.
l If the encapsulation types and MTUs of both ends are the same, go to Step 2.
NOTE
The same encapsulation type and MTU on both ends are two prerequisites for the VSI to go Up.
Step 2 Check that site IDs of both ends are different.

[HUAWEI-vsi-tt2] display this
#
vsi tt2 auto
pwsignal bgp
site 1 range 10 default-offset 0
#
return
l If the site IDs of both ends are the same, run the site site-id [ range site-range ] [ defaultoffset { 0 | 1 } ] command to change the site ID of either end, ensuring that the site IDs of
both ends are different.
l If the site IDs of both ends are different, go to Step 4.
NOTE
Site IDs of the same VSI cannot be the same.
Step 3 Check that the BGP session between both ends is in the Established state.
Run the display bgp vpls peer [ ipv4-address verbose | verbose ] [ | count ] [ | { begin |
exclude | include } regular-expression ] command to check the BGP session between both ends.
<HUAWEI> display bgp vpls peer
Total number of peers : 1
Peer
1.1.1.1
V
4
AS
100
MsgRcvd
14
Peers in established state : 1

MsgSent
16
OutQ Up/Down
0 00:10:06
State PrefRcv
Established
0
l If the BGP session is not in the Established state, refer to the section The BGP Peer
Relationship Fails to Be Established to locate the fault and establish the BGP session.
l If the BGP session between both ends is in the Established state, go to Step 4.
Issue 02 (2011-09-10)

64

NOTE
The Established status of the BGP session is one of the prerequisites for both ends to perform the L2VPN
negotiation.
Step 4 Check whether the VSI has selected a tunnel.

Run the display vsi name vsi-name verbose command to check the following:
l Check whether the Tunnel ID field is displayed as 0x0. If so, it indicates that the VSI does
not select a tunnel.
l Check the Tunnel Policy Name field. If this field is not displayed, it indicates that the VSI
selects an LDP LSP or no tunnel policy is configured for the VSI. If the VSI selects an MPLSTE tunnel, a tunnel policy must be configured. The value of the Tunnel Policy Name field
indicates the tunnel policy of the VSI. You can view details of the tunnel policy by running
the display this command in the corresponding tunnel policy view.
#
tunnel-policy p1
#
NOTE

in the tunnel policy view, you also need to configure the mpls te reserved-for-binding command in the
tunnel interface view.
If the tunnel between both ends is not Up, refer to the session LDP LSP Goes Down or TE
Tunnel Is Down to locate the fault and ensure that the tunnel goes Up. If the tunnel between
both ends is Up and the TE interfaces are correctly configured, go to Step 6.
NOTE
The Up status of the tunnel is one of the prerequisites for the VSI to go Up.
Step 5 Check that the site ID of either end is smaller than the sum of the range and default offset of the
other end.
#
vsi tt2 auto
pwsignal bgp
route-distinguisher 168.1.1.1:1
#
returen
l If the site ID of either end is equal to or greater than the sum of the range and default offset
of the other end, modify either the site ID of the local end or the range of the remote end.
l If the site ID of either end is smaller than the sum of the range and default offset of the other
end, go to Step 6.
Step 6 Check that AC interfaces of both ends are Up.
Run the display vsi name vsi-name verbose command on both ends to check whether the
interfaces corresponding to the Interface Name field are in the Up state.
l If not, refer to the section "Physical Interconnection & Interface Type" to locate the fault and
ensure that the AC interfaces go Up.
l If the AC interfaces on both ends are Up, go to Step 8.
Issue 02 (2011-09-10)

65

----End

Relevant Alarms
None.
Relevant Logs
None.
2.3 VSI Goes Up Only on One End

procedure for the fault that the VSI goes Up only on one end.
2.3.1 Common Causes

This fault is commonly caused by the following:
l
The local end is specified as a UPE by the remote end.
Multiple AC interfaces in the Up state are bound to the VSI on the local end but no tunnel
is selected.

After VPLS is configured, the VSI goes Up only on one end.
Issue 02 (2011-09-10)

66

Figure 2-3 Troubleshooting flowchart for the fault that the VSI goes Up only on one end
The VSI is Up only on the
local end
Is the local
end bound to two or more
AC interfaces in the Up
state?
Yes
End
No
Does
the remote end specify
the local end as
the UPE?
Yes
End
No

NOTE
Procedure
Step 1 Check that multiple AC interfaces on the local end are bound to the VSI.
***VSI Name
:
Administrator VSI
:
Isolate Spoken
:
VSI Index
:
PW Signaling
:
Member Discovery Style :
PW MAC Learn Style
:
Encapsulation Type
:
MTU
:
Diffserv Mode
:
Service Class
:
Color
:
DomainId
:
Domain Name
:
Tunnel Policy Name
:
Ignore AcState
:
Create Time
:
VSI State
:
VSI ID
*Peer Router ID
Issue 02 (2011-09-10)
verbose
tt
no
disable
3
ldp
static
unqualify
vlan
1500
uniform
--255
p1
disable
up
: 101
: 2.2.2.2

67

VC Label
Peer Type
Session
Tunnel ID
Broadcast Tunnel ID
CKey
NKey
StpEnable
PwIndex
:
:
:
:
:
:
:
:
:
187393
dynamic
up
0xc0060401
0xc0060401
6
5
0
0
Interface Name
State
Last Up Time
Total Up Time
Interface Name
State
Last Up Time
Total Up Time
:
:
:
:
:
:
:
:
up
2010/02/05 06:36:57
up
2010/02/07 12:33:13
If two or more AC interfaces are bound to the VSI, but the fault persists, go to Step 2.
Step 2 Check that the remote end specifies the local end as the UPE.
[HUAWEI-vsi-tt-ldp] display this
#
vsi-id 101
peer 1.1.1.1 upe
#
l If the remote end specifies the local end as the UPE, it is normal to find that the VSI goes
Up only on one end.
l If the remote end does not specify the local end as the UPE, but the fault persists, go to Step
3.
----End

Relevant Alarms
None.
Relevant Logs
None.
2.4 A Huawei Device Cannot Establish a PW with Another

Vendor's Device on a Kompella VPLS Network
procedure for the fault that a Huawei device cannot establish a PW with another vendor's device
on a Kompella VPLS network.
Issue 02 (2011-09-10)

68

2.4.1 Common Causes

l
The vpls bgp encapsulation { ethernet | vlan } command is not configured in the system
view.
The ignore-mtu-match command is not configured in the VSI view.
The default offset of another vendor's device is 1 and cannot be modified. When a Huawei
device communicates with the device, the default offset of the Huawei device should be
set to 1 and the site ID should not be set to 0.

After Kompella VPLS is configured, the Huawei device cannot establish a PW with another
vendor's device.
Issue 02 (2011-09-10)

69

Figure 2-4 Troubleshooting flowchart for the fault that the Huawei device cannot establish a
PW with another vendor's device
A Huawei device cannot
establish a PW with another
vendor's device
on a Kompella VPLS
network
Is the vpls bgp

encapsulation { ethernet |
vlan } command configured
in the system view?
No
Configure this
command and check
whether the fault is
rectified
Yes
End
No
Yes
Is the
ignore-mtu-match
command configured in the
VSI view?
No
Configure this
command and check
whether the fault is
rectified
Yes
End
No
Yes
Is the site
ID of the Huawei device set
to 0?
Yes
Set the site ID to 1
No
Yes
Is fault rectified?
End
No

NOTE
Issue 02 (2011-09-10)

70

Procedure
Step 1 Check that the vpls bgp encapsulation { ethernet | vlan } command is configured in the system
view.
l If the command is not configured in the system view, configure the command first.
l If the command is configured in the system view, go to Step 2.
NOTE
On the other vendor's device, the signaling command is configured by default in the BGP L2VPN address
family view. In this case, the BGP Update packet sent by this device contains not only the VPLS address
family (AFI=25, SAFI=65), but also a non-standard CSV field. Although this field is valid for Kompella
VLL, it is not specified in RFC 4761 for VPLS. The Huawei device uses different address families for
VPLS and Kompella VLL. After receiving a BGP Update packet from the other vendor's device, the Huawei
device parses the packet. After identifying the VPLS address family, the Huawei device processes the
packet as a VPLS packet. Then, the Huawei device identifies the non-standard CSV field, which should
not have been in the VPLS packet. Therefore, the Huawei device considers that the length of the BGP
Update packet is incorrect, and fails to establish the BGP peer relationship with the other vendor's device.
Step 2 Check that the ignore-mtu-match command is configured in the VSI view.
l If the command is not configured in the VSI view, configure the command first.
l If the command is configured in the VSI view, go to Step 3.
NOTE
This command is used to ignore the MTU negotiation with another vendor's device.
Step 3 Check that default-offset of the Huawei device is set to 1.

#
vsi tt2 auto
pwsignal bgp
route-distinguisher 168.1.1.1:1
#
return
l If default-offset is not set to 1, set it to 1.

l If default-offset is set to 1, go to Step 4.
----End

Relevant Alarms
None.
Relevant Logs
None.
Issue 02 (2011-09-10)

71


2.5.1 VPLS Services Fail
Fault Symptom
As shown in Figure 2-5, after a Huawei device replaces another vendor's device and functions
as PE1, only VPLS services fail.
Figure 2-5 Networking diagram of Martini VPLS
Outbound
Inbound
MAN
CE2
CE1
PE1
Huawei device
PE2
(Another vendor's device)
Server
Martini VPLS
Fault Analysis
NOTE
After a Huawei device replaces another vendor's device, only VPLS services fail. You can exclude the
possibility of a link failure or the failure of another device.
1.
Run the display current-configuration command on PE1 to check whether the

configurations are correct and consistent with those of PE2. You can find that
configurations of PE1 are correct and consistent with those of PE2.
2.
Run the display vpls connection command on PE1 to check the VCState field. You can
find that VCState is Up, indicating that a Layer 2 tunnel is established.
3.
When CE1 pings Server, run the display traffic-statistics vsi vsi-name [ peer peeraddress [ negotiation-vc-id vc-id ] ] command on PE1 to check whether the packet sending
and receiving process is normal. You can find that packets can be correctly sent and
received.
4.
When CE1 pings Server, you can capture VPLS packets in the inbound and outbound
directions of PE1 on another device of the MAN.
A captured VPLS packet in the inbound direction of PE1 is shown as follows:
0018
01FE
0001
0301
821D
0019
0800
0019
2010
E019
0604
E019
0014
0D9E
0002
0D9E
1CD2
0019
0019
0303
FC06
21D5
21D5
0302
8847
5FD6
5FD6
0000
22C0
0806
0303
0000
As indicated by the 0806 field, the captured VPLS packet sent from PE2 carries no VLAN
tag and is just a common ARP packet. PE1 and PE2, however, are configured with the
Issue 02 (2011-09-10)

72

encapsulation mode of VLAN, causing PE1 to add a VLAN tag to the VPLS packet. After
adding a VLAN tag to the VPLS packet, PE1 forwards the packet in the outbound direction.
A captured VPLS packet in the outbound direction of PE1 is shown as follows:
0019 E019 0D9E 0019 21D5 5FD6 8100 019b
0800 0604 0002 0019 21D5 5FD6 0303 0301
0019 E019 0D9E 0303 0302 0000 0000 0000
You can find that PE1 replaces the 0806 field (ARP packet identifier) with the 8100 field
(VLAN packet identifier). As a result, VPLS services fail. If the VLAN encapsulation mode
of PE2 (another vendor's device) is modified to send VLAN tags, or PE1 and PE2 are
configured with the encapsulation mode of Ethernet, the fault can be rectified.
Procedure
l
Solution 1: Modify the VLAN encapsulation mode of another vendor's device to send
VLAN tags.
Solution 2: Change the encapsulation mode on PE1 and PE2 to Ethernet. The Huawei device
(PE1) can be configured as follows:
1.
2.
Run the vsi vsi-name command to enter the VSI view.
3.
Run the encapsulation ethernet command to set the VSI encapsulation mode as
Ethernet.
After the preceding configurations, CEs can ping each other successfully, and VPLS
services become normal.
----End
Summary
Why can the Layer 2 tunnel be Up when PE1 has incorrectly parsed packets?
To answer this question, check the configurations of PE2. You can find that the VPLS sending
and receiving on PE2 is in the hybrid mode. That is, PE2 can process any types of packets; when
receiving a VPLS packet carrying a VLAN tag, PE2 removes the VLAN tag and then forwards
the VPLS packet. This is the cause for the problem.
As defined by RFC 4448, if a packet transmitted on a PW is encapsulated to the tagged mode,
the packet must carry a VLAN tag.
Issue 02 (2011-09-10)

73

2.5.2 VSIs Cannot Be Up in LDP Signaling Mode

Fault Symptom
Figure 2-6 Networking diagram of VPLS
Loopback1
2.2.2.9/32
Loopback1
1.1.1.9/32
PE1
Ethernet1/0/0
POS2/0/0
168.1.1.1/24
POS1/0/0
168.1.1.2/24
Loopback1
3.3.3.9/32
POS2/0/0
169.1.1.1/24
P
POS1/0/0
169.1.1.2/24
CE1
PE2
Ethernet2/0/0
CE2
VPLS in LDP signaling mode is configured on both PE1 and PE2. After the configuration, the
VSI on both PEs cannot be Up.
Then PE1 initiates CE-Ping to detect the IP address of CE2, but the detection fails. Locating the
fault, you find that the VSI cannot go Up.
Fault Analysis
1.
Check the VSI status on PE1 and PE2.

Run the display vsi verbose command.
The display on PE1 is as follows.
VSI Name
: v1
VSI Index
PW Signaling
PW MAC Learn Style
Encapsulation Type
MTU
VSI State
VSI ID
*Peer Router ID
VC Label
Session
Tunnel ID
Interface Name
State
:
:
:
:
:
:
:
:
:
:
:
:
:
:
0
ldp
static
unqualify
vlan
1500
down
1
3.3.3.9
17409
up
0x6002002,
Ethernet1/0/0
up

VSI Name
:
VSI Index
PW Signaling
PW MAC Learn Style
Encapsulation Type
MTU
Issue 02 (2011-09-10)
v1
: 0
: ldp
: static
: unqualify
: vlan
: 1500

74

VSI State
VSI ID
*peer Router ID
VC Label
Session
Tunnel ID
Interface Name
State
:
:
:
:
:
:
:
:
down
1
2.2.2.9
17408
up
0x6002001,
Ethernet2/0/0
up
ACs on both ends are Up. The tunnel on both ends of a PW is in existence, and the tunnel
ID is not 0x0.
2.
According to the displayed PW information, you can find that the designated remote LDP
peer of the PE2 is not correct. It should be 1.1.1.9 rather than 2.2.2.9. Then modify the peer.
Procedure
Step 1 Run the display vsi verbose command on PEs.
Step 2 Check the status of VSI and AC. Find that the VSI is Down, but AC is Up.
Step 3 Check the status of the PW. Find that the PW cannot be set up.
Step 4 Check whether the tunnel is available. Find that the tunnel is ready.
Step 5 Find that the designated remote LDP peer of the PE2 is not correct according to the displayed
PW information. The incorrectness makes the PW establishment failed. It should be designated
as 1.1.1.9 rather than 2.2.2.9. Modify the peer.
Step 6 Reconfigure the remote LDP peer of the PE2, which means to designate it as 1.1.1.9. Then the
PW is established successfully.
----End
Summary
If the signaling protocol is LDP and the VSI cannot be Up, the errors related to the peer are as
follows:
l
The peer is specified incorrectly.
The address of the peer is not the peer LSR-ID. The LDP remote session then cannot be
established.
The LSR-ID of the peer is re-defined. Then the LDP remote session cannot be set up.
If a VSI is Up, there must be at least two ACs are Up, or at least one AC is Up and one PW is
Up.
To locate the fault, you can check the status of the AC and PW first.
l
It is simple to let an AC go Up. You must bind the AC with a physical interface, and the
line protocol state of the interface must be Up.
There are many conditions for a PW to go Up, such as the correct configurations of MTU,
encapsulation type, VSI ID, and remote peer. The key is that the local and the remote ends
can receive labels from each other.
You can run the display vsi remote { ldp | bgp } command to find which device is faulty
according to the label receiving.
Issue 02 (2011-09-10)

75

2.5.3 Packets Cannot Be Forwarded Successfully Between Two PEs

Though VSIs Are Up
Fault Symptom
After configuring VPLS, check the VSI status on PEs. You find that both VSIs are Up, but the
packets cannot be forwarded successfully between two PEs.
Fault Analysis
1.
Check whether the PW is available.

Run the display vsi verbose command to check whether the PW is available.
If the PW is not available, check whether the delivering status of the PW is "up", as shown
below:
l If the status is not "up", it shows that the forwarding information is not delivered to the
interface board, which leads to the failure of the forwarding.
l If the status is "up" but the forwarding still fails, check the operating status of the
interface board.
2.
Check the MAC limit.

If the PW is available, but packets cannot be forwarded between PEs, run the display
current-configuration | begin vsi vsi-name command to check the MAC limit. If the
number of MAC address entries exceeds the MAC limit, re-configure the MAC limit.
3.
Check whether the BGP peer is reestablished.

If the number of MAC address entries does not exceed the MAC limit, run the display bgp
peer peer-address command to check whether the BGP peer is set up. When the BGP peer
is being re-established, the VSI status remains Up in this short period.
4.
Check the encapsulation types of PEs on both ends.

If the BGP peer is set up, run the display current-configuration | begin vsi vsi-name
command to check the encapsulation types of PEs on both ends. If the types are different,
re-configure them to be the same.
If the fault persists, contact the Huawei technical personnel.
Procedure
Step 1 Run the display vsi command to check whether the status of the PW is up.
Step 2 Run the display vpls connection command to check whether the PW is available.
Step 3 If the status is "up", check whether the operating status of the interface board is normal.
----End
Summary
The fault occurs when one of the following conditions is met:
l
The PW information is not delivered to the interface board.
The number of MAC address entries exceeds the MAC limit.
When the BGP peer is being re-established, the VSI state remains Up in this short period.
Issue 02 (2011-09-10)

76

The encapsulation types on PEs of both ends are different.
2.5.4 VSIs Cannot Be Up in BGP Signaling Mode

Fault Symptom
PE1 and PE2 establish IBGP, and are configured with VSIs respectively. After the configuration,
you find that VSIs on both PEs cannot go Up.
Loopback1
2.2.2.9/32
Loopback1
1.1.1.9/32
PE1
Ethernet1/0/0
POS2/0/0
168.1.1.1/24
POS1/0/0
168.1.1.2/24
Loopback1
3.3.3.9/32
POS2/0/0
169.1.1.1/24
P
POS1/0/0
169.1.1.2/24
CE1
PE2
Ethernet2/0/0
CE2
Fault Analysis
1.
Check the VSI status on PE1 and that on PE2.

***VSI Name
VSI Index
PW Signaling
PW MAC Learn Style
Encapsulation Type
MTU
VSI State
BGP RD
SiteID/Range/Offset
Import vpn target
Export vpn target
Local Label Block
Interface Name
State
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
bgp1
0
bgp
auto
unqualify
vlan
1500
down
1:1
1/10/0
2:2,
2:2,
19456/10/0,
Ethernet1/0/0
up

***VSI Name
: bgp1
VSI Index
: 0
PW Signaling
: bgp
Member Discovery Style : auto
PW MAC Learn Style
: unqualify
Encapsulation Type
: vlan
MTU
: 1500
VSI State
: down
Issue 02 (2011-09-10)

77

BGP RD
SiteID/Range/Offset
Import vpn target
Export vpn target
Local Label Block
Interface Name
State
2.
:
:
:
:
:
:
:
1:2
2/10/0
2:2,
2:2,
19456/10/0,
Ethernet2/0/0
up
Check whether PEs can receive the remote label.

Run the display vsi remote bgp command on PE1 and PE2. No information is displayed,
which indicates that PEs have not received the remote label.
In this case, the BGP configuration may be faulty.
Procedure
Step 1 Check the AC status on both PEs, finding that both ACs are Up.
Step 2 Run the display vsi remote bgp command, and find no display. This indicates that the label is
not received.
Step 3 Check whether the VPN targets match.
Step 4 If the VPN targets match, check whether a tunnel is available.
Step 5 If the tunnel is available, run the display bgp peer command to check whether the BGP neighbor
relationship is established.
Step 6 If the BGP neighbor relationship is set up, run the display bgp vpls all command to check
whether the remote label block is received.
Step 7 If the remote label block is not received, check the BGP configuration. You can find that the
VPLS address family is not configured. After configuring the VPLS address family, you can
rectify the fault.
----End
Summary
VPLS in BGP mode and VPLS in LDP mode are configured differently. The major difference
is that VPLS address family need to be configured, and the peer in the address family need to
be enabled in BGP mode.
When using the BGP signaling, check whether the BGP VPLS peer is specified and the remote
label block can be received. The VSI status is still determined by the status of the AC and PW.
In addition, you need to pay attention to the setting of the encapsulation type and MTU.
Issue 02 (2011-09-10)

78

2.5.5 PEs Cannot Interwork Though VSIs Are Up

Fault Symptom
Loopback1
2.2.2.9/32
Loopback1
1.1.1.9/32
PE1
Ethernet1/0/0
POS2/0/0
168.1.1.1/24
POS1/0/0
168.1.1.2/24
Loopback1
3.3.3.9/32
POS2/0/0
169.1.1.1/24
P
POS1/0/0
169.1.1.2/24
CE1
PE2
Ethernet2/0/0
CE2
VPLS in BGP mode is configured on PE1 and PE2. Although VSIs go Up, PEs cannot interwork.
Fault Analysis
1.
Check the VSI status on PE1 and PE2.

The display on PE1 is as follow:
***VSI Name
: v1
VSI Index
: 0
PW Signaling
: bgp
Member Discovery Style : auto
PW MAC Learn Style
: unqualify
Encapsulation Type
: vlan
MTU
: 1500
VSI State
: up
BGP RD
: 168.1.1.1:1
SiteID/Range/Offset
: 3/10000/0
Import vpn target
: 100:1,
Export vpn target
: 100:1,
Remote Label Block
: 141293/10000/0,
Local Label Block
: 140288/10000/0,
Interface Name
: Vlan100
State
: up
*Peer Ip Address
: 3.3.3.9
PW State
: up
Local VC Label
: 140289
Remote VC Label
: 141296
PW Type
: label
Tunnel ID
: 0x1009,
PW Type
: label
Tunnel ID
: 0x1009,
The display on PE2 is as follows:

***VSI Name
VSI Index
PW Signaling
Issue 02 (2011-09-10)
: v1
: 0
: bgp

79


PW MAC Learn Style
Encapsulation Type
MTU
VSI State
BGP RD
SiteID/Range/Offset
Import vpn target
Export vpn target
Remote Label Block
Local Label Block
Interface Name
State
*Peer Ip Address
PW State
Local VC Label
Remote VC Label
PW Type
Tunnel ID
: auto
: unqualify
: ethernet
: 1500
: up
: 169.1.1.2:1
: 3/10000/0
: 100:1,
: 100:1,
:, 140288/10000/0
: 141293/10000/0,
: Vlan100
: up
: 1.1.1.9
: up
: 141296
: 140289
: label
: 0x1009,
The status of ACs on both ends is Up. Check the PW information on PE and find the tunnel
information exists. The tunnel ID is not 0x0. See the display of Tunnel ID as above.
2.
Run the display vsi remote bgp command on PE2.

The display is as follows:
Total Number
: 1
**BGP RD
NextHop
EncapType
MTU
Export vpn target
SiteID
Remote Label Block
:
:
:
:
:
:
:
169.1.1.2:1
200.200.200.12
vlan
1500
100:1,
3
140288/10000/0,
Number
: 1
The preceding display shows that after receiving a VPLS packet, PE2 assumes that the
encapsulation type of this packet is ethernet. However, according to Step 1, the
encapsulation type of the VPLS packet sent by PE1 is vlan. PE1 and PE2 cannot agree on
the encapsulation type of the VPLS packet. PEs, hence, cannot interwork.
Procedure
Step 1 Run the display vsi verbose command on PEs.
Step 2 Check VSI and AC, finding that both are in the Up state.
Step 3 Check whether the tunnel is available, finding that the tunnel is ready.
Step 4 Run the display vsi remote bgp command on one PE to check the encapsulation type of the
VPLS packet to be received by the PE, finding that the encapsulation type is different from that
sent by the peer PE.
Step 5 Run the vpls bgp encapsulation command on the local PE to re-designate the encapsulation
type. Ensure that both PEs agree on the encapsulation type of the VPLS packets.
----End
Summary
The sender and the receiver should agree on the encapsulation type of the VPLS packet.
Otherwise, interworking between PEs cannot be realized.
Issue 02 (2011-09-10)

80

3 VLL Troubleshooting
VLL Troubleshooting
About This Chapter

3.1 The VC of Martini VLL Cannot Be Up
3.2 The VC of Kompella VLL Cannot Be Up
procedure for the fault that the VC of Kompella VLL cannot be Up.
3.3 A PW of Kompella VLL Cannot Be Up When the AC Interfaces at Both Ends of the PW
Are Ethernet Sub-Interfaces and Adopt the tagged Encapsulation Type
This section provides a step-by-step troubleshooting procedure for the fault that a PW of
Kompella VLL cannot be Up when the AC interfaces at both ends of the PW are Ethernet subinterfaces and adopt the tagged encapsulation type.
3.4 The VC Cannot Be Up When a Huawei Device Communicates with a Non-Huawei Device
Through Kompella VLL
This section provides a step-by-step troubleshooting procedure for the fault that the VC cannot
be Up when a Huawei device communicates with a non-Huawei device through Kompella VLL.
Issue 02 (2011-09-10)

81

3.1 The VC of Martini VLL Cannot Be Up

3.1.1 Common Causes
l
The encapsulation types of both ends of the VC are different.
The MTUs of both ends of the VC are different.
The VC IDs of both ends of the VC are different.
The control word configuration of both ends of the VC are different.
The LDP session is not Up.
The tunnel policy is incorrectly configured so that the TE tunnel is not adopted as the public
network tunnel.
The tunnel on the local or remote end is not Up.
The AC interface on the local or remote end is not Up.

The VC cannot be Up after Martini VLL is configured.
Issue 02 (2011-09-10)

82

Figure 3-1 Troubleshooting flowchart for the VC of Martini VLL failing to be Up

A VC of Martini
VLL cannot be
Up
Encapsulation
types of both ends
the same?
No
Fault rectified?
End
Yes
End
No
Yes
MTUs of
both ends the
same?
No
Fault rectified?
No
Yes
VC IDs of both
ends the same
No
Fault rectified?
Yes
End
No
Yes
Control
words of both ends
the same
No
Fault rectified?
Yes
End
No
Yes
No
LDP session
is Up?
Fault rectified?
Yes
End
No
Yes
Tunnel is Up?
No
Fault rectified?
Yes
End
No
Yes
AC interfaces
are Up?
Yes
Yes
No
Fault rectified?
Yes
End
No
Seek technical
support
Issue 02 (2011-09-10)

83


NOTE
Procedure
Step 1 Check that the two ends of the VC are configured with the same encapsulation type and MTU.
Run the display mpls l2vc vc-id command to check VC information.
<HUAWEI> display mpls l2vc 102
total LDP VC : 1
1 up
*client interface
:
session state
:
AC status
:
VC state
:
VC ID
:
VC type
:
destination
:
local VC label
:
control word
:
forwarding entry
:
local group ID
:
manual fault
:
active state
:
link state
:
local VC MTU
:
tunnel policy name
:
traffic behavior name:
PW template name
:
primary or secondary :
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
0 down
up
up
up
102
VLAN
2.2.2.2
146433
remote VC label
: 146432
disable
exist
0
not set
active
up
1500
remote VC MTU
: 1500
---primary
2010/02/17 08:23:07
If the two ends are configured with different encapsulation types or MTUs, change the
encapsulation type or MTU of one end to be the same as that of the other end.
If the two ends are configured with the same encapsulation type and MTU but the fault persists,
go to Step 2.
NOTE
A VC can be Up only when the two ends of the VC are configured with the same encapsulation type and
MTU.
Step 2 Check that the VC IDs of both ends of the VC are the same.
total LDP VC : 1
1 up
*client interface
session state
AC status
VC state
VC ID
VC type
destination
local VC label
control word
Issue 02 (2011-09-10)
:
:
:
:
:
:
:
:
:
0 down
up
up
up
102
VLAN
2.2.2.2
146433
remote VC label
disable

: 146432
84

forwarding entry
:
local group ID
:
manual fault
:
active state
:
link state
:
local VC MTU
:
tunnel policy name
:
PW template name
:
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
exist
0
not set
active
up
1500
remote VC MTU
: 1500
---primary
2010/02/17 08:23:07
If the VC IDs of both ends of the VC are different, change the VC ID of one end to be the same
as that of the other end.
If the VC IDs of both ends of the VC are the same but the fault persists, go to Step 3.
NOTE
A VC can be Up only when the VC IDs of both ends of the VC are the same.
Step 3 Check that the CWs configuration of both ends of the VC are the same.
total LDP VC : 1
1 up
*client interface
:
session state
:
AC status
:
VC state
:
VC ID
:
VC type
:
destination
:
local VC label
:
control word
:
forwarding entry
:
local group ID
:
manual fault
:
active state
:
link state
:
local VC MTU
:
tunnel policy name
:
PW template name
:
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
0 down
up
up
up
102
VLAN
2.2.2.2
146433
remote VC label
: 146432
disable
exist
0
not set
active
up
1500
remote VC MTU
: 1500
---primary
2010/02/17 08:23:07
If the CWs configuration of both ends of the VC are different, change the VC ID of one end to
be the same as that of the other end.
If the CWs configuration of both ends of the VC are the same but the fault persists, go to Step
4.
NOTE
A VC can be Up only when the CWs of both ends of the VC are the same.
Step 4 Check that the LDP session between the two ends is Up.
total LDP VC : 1
1 up
Issue 02 (2011-09-10)
0 down

85

*client interface
:
session state
:
AC status
:
VC state
:
VC ID
:
VC type
:
destination
:
local VC label
:
control word
:
forwarding entry
:
local group ID
:
manual fault
:
active state
:
link state
:
local VC MTU
:
tunnel policy name
:
PW template name
:
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
up
up
up
102
VLAN
2.2.2.2
146433
remote VC label
: 146432
disable
exist
0
not set
active
up
1500
remote VC MTU
: 1500
---primary
2010/02/17 08:23:07
If the LDP session is Down, see "An LDP Session Is Down" to locate the fault and then turn the
LDP session Up.
If the LDP session is Up but the fault persists, go to Step 5.
NOTE
A VC can be set up only when the LDP session is Up.
Step 5 Check whether the PW has selected a tunnel.

Run the display mpls l2vc vc-id command.
l Check the VC tunnel/token info field in the command output. If VC tunnel/token info is
displayed as 0 tunnels/tokens, it indicates that no tunnel is selected by a PW.
l Check the tunnel policy name field in the command output.
If tunnel policy name is displayed as "-", it indicates that an LDP LSP is used as the
tunnel for a PW or no tunnel policy is configured. An MPLS TE tunnel can be used for
a PW only after a tunnel policy is configured.
If tunnel policy name is not displayed as "-", it indicates that a tunnel policy is adopted.
In this case, you can run the display this command in the tunnel policy view to view the
tunnel policy configuration.
#
tunnel-policy p1
#
If the tunnel is Down, see "An LSP Is Down" or "A TE Tunnel Is Down" to locate the fault and
then turn the tunnel Up. If the tunnel is Up and the TE interfaces are correctly configured, go to
Step 6.
NOTE
A VC can be Up only when the tunnel that bears the VC is Up.
Step 6 Check that the AC interfaces on the two ends are Up.
Issue 02 (2011-09-10)

86

Run the display mpls l2vc vc-id command on both ends of the VC to check whether the AC
status field is displayed as Up.
l If the AC interfaces on the two ends are Down, see "Physical Interface Interconnection" to
locate the fault and turn the AC interfaces Up.
l If the AC interfaces on the two ends are Up, go to Step 7.
NOTE
A VC can be Up only when the AC interfaces on both ends of the VC are Up.
----End

Relevant Alarms
None.
Relevant Logs
None.
3.2 The VC of Kompella VLL Cannot Be Up

procedure for the fault that the VC of Kompella VLL cannot be Up.
3.2.1 Common Causes

l
The CE-IDs of both ends are the same.
ce-offset of the local end is different from ce-id of the remote end.
The BGP session is not in the Established state.
The tunnel policy is incorrectly configured so that the TE tunnel cannot be adopted as the
public network tunnel.
ce-id of the local end is greater than the sum of site-range and default-offset set on the
remote end.

Issue 02 (2011-09-10)

87

The VC cannot be Up after Kompella VLL is configured.

Figure 3-2 Troubleshooting flowchart for the VC of Kompella VLL failing to be Up
A VC of
KompellaVLL
cannot be Up
Encapsulation
types of both ends
the same?
No
Fault rectified?
Yes
No
Yes
MTUs
of both ends the
same?
No
Fault rectified?
Yes
No
Yes
CE IDs
of both ends the
same?
No
Fault rectified?
Yes
No
Yes
Local CE
offset the same as
remote CE ID?
No
Fault rectified?
No
Yes
BGP session
established
No
Fault rectified?
Yes
No
Yes
No
Tunnel is Up?
Fault rectified?
Yes
No
Yes
AC interfaces are
Up?
Yes
Yes
No
Fault rectified?
Yes
No
Seek technical
support
Issue 02 (2011-09-10)

End
88


NOTE
Procedure
<HUAWEI> display mpls l2vpn vpn1
VPN name: vpn1, encap type: ethernet, local ce number(s): 1, remote ce number(s):
1
route distinguisher: 100:1, MTU: 1500
import vpn target: 100:1,
export vpn target: 100:1,
remote vpn site(s) :
no. remote-pe-id
route-distinguisher
1
1.1.1.1
100:1
If the two ends are configured with different encapsulation types or MTUs, run the mpls
l2vpn l2vpn-name encapsulation vc-type command in the system view to change the
encapsulation type of one end to be the same as that of the other end, or run the mtu mtuvalue command in the MPLS-L2VPN instance view to change the MTU of one end to be the
same as that of the other end.
go to Step 2.
NOTE
MTU.
Step 2 Check whether ce-ids of both ends of the VC are the same.
<HUAWEI> display mpls l2vpn connection interface GigabitEthernet 2/0/2.10
conn-type: remote
local vc state:
up
remote vc state:
up
local ce-id:
2
local ce name:
ce2
remote ce-id:
1
intf(state,encap):
GigabitEthernet2/0/2.10(up,ethernet)
peer id:
1.1.1.1
route-distinguisher:
100:1
local vc label:
179221
remote vc label:
179222
tunnel policy:
default
primary or secondary:
primary
forward entry exist or not: true
forward entry active or not:true
manual fault set or not:
not set
AC OAM state:
up
BFD for PW session index:
-BFD for PW state:
invalid
BFD for LSP state:
true
Local C bit is not set
Remote C bit is not set
tunnel type:
lsp
tunnel id:
0x2008004
Issue 02 (2011-09-10)

89

If ce-ids of both ends are the same, run the ce ce-name id ce-id command to change ce-id of one
end to be different from that of the other end.
If ce-ids of both ends of the VC are different but the fault persists, go to Step 4.
NOTE
ce-ids of the PW of Kompella VLL cannot be the same.
Step 3 Check whether ce-offset of the local end is the same as ce-id of the remote end.
Check the configurations in the MPLS-L2VPN-CE view.
[HUAWEI] mpls l2vpn vpn1
[HUAWEI-mpls-l2vpn-vpn1] display this
#
mpls l2vpn vpn1 encapsulation ppp
ce ce1 id 2 range 10 default-offset 0
connection ce-offset 1 interface Pos1/0/0
#
return
If ce-offset of the local end is different from ce-id of the remote end, run the undo connection
ce-offset id command in the MPLS-L2VPN-CE view to delete the CE connection first, and then
run the connection [ ce-offset id ] interface interface-type interface-number command in the
MPLS-L2VPN-CE view to set ce-offset of the local end to be the same as ce-id of the remote
end.
If ce-offset of the local end is the same as ce-id of the remote end but the fault persists, go to
Step 4.
NOTE
A Kompella VLL can be set up only when ce-offset of the local end is the same as ce-id of the remote end.
Step 4 Check that the BGP session between the two ends is Established.
Run the display bgp l2vpn peer [ ipv4-address verbose | verbose ] command to check the status
of the BGP session.
<HUAWEI> display bgp l2vpn peer
local AS number : 100
Total number of peers : 1
Peer
PrefRcv
AS
1.25.1.3
Established
100
Peers in established state : 1

MsgRcvd
MsgSent
OutQ
Up/Down
13433
836
00:00:39
State
If the BGP session is not in the Established state, see "The BGP neighbor relationship cannot
be established" to turn the BGP session to the Established state.
If the BGP session is in the Established state but the fault persists, go to Step 4.
NOTE
A Kompella VLL can be set up only when the BGP session is in the Established state.
Step 5 Check whether the VC has selected a tunnel.

Run the display mpls l2vpn connection interface interface-type interface-number command.
Issue 02 (2011-09-10)

90

l Check the tunnel id field in the command output. If tunnel id is displayed as 0x0, it indicates
that no tunnel is adopted for the VC.
l Check the tunnel policy field in the command output. If tunnel policy is displayed as
default, it indicates that an LDP LSP is adopted as a VC or no tunnel policy is configured.
An MPLS TE tunnel can be adopted as a PW only after a tunnel policy is configured. tunnel
policy indicates the tunnel policy adopted by the VC. You can run the display this command
in the tunnel policy view to view the tunnel policy configuration.
#
tunnel-policy p1
#
NOTE

in the tunnel policy view, you also need to run the mpls te reserved-for-binding command on the tunnel
interface.
Step 6.
NOTE
Step 6 Check that ce-id of the local end is smaller than the sum of site-range and default-offset set on
the remote end.
Check the configurations in the MPLS-L2VPN-CE view.
#
#
return
If ce-id of the local end is not smaller than the sum of site-range and default-offset set on the
remote end, run the ce ce-name [ id ce-id [ range ce-range ] [ default-offset ce-offset ] ]
command to change ce-id of the local end or site-range of the remote end, ensuring that ce-id
of the local end is smaller than the sum of site-range and default-offset set on the remote end.
If ce-id of the local end is smaller than the sum of site-range and default-offset set on the remote
end, and ce-id of the remote end is smaller than the sum of site-range and default-offset set on
the local end, go to Step 7.
Run the display mpls l2vpn connection interface interface-type interface-number command
on the two ends to check whether the AC interfaces are Up.
Issue 02 (2011-09-10)

91

----End

Relevant Alarms
None.
Relevant Logs
None.
3.3 A PW of Kompella VLL Cannot Be Up When the AC

Interfaces at Both Ends of the PW Are Ethernet SubInterfaces and Adopt the tagged Encapsulation Type
This section provides a step-by-step troubleshooting procedure for the fault that a PW of
Kompella VLL cannot be Up when the AC interfaces at both ends of the PW are Ethernet subinterfaces and adopt the tagged encapsulation type.
3.3.1 Common Causes

This fault is commonly caused by the following:
l
The encapsulation type of the VPN instance is different from that of the PW.

NOTE
Procedure
Step 1 Check that the encapsulation type of the PW is the same as that of the VPN instance.
Check the encapsulation type of the VPN instance.
<HUAWEI> display mpls l2vpn vpn1
VPN name: vpn1, encap type: ethernet, local ce number(s): 1, remote ce number(s)
: 1
route distinguisher: 100:1, MTU: 1500
import vpn target: 200:1,
export vpn target: 200:1,
remote vpn site(s) :
no. remote-pe-id
route-distinguisher
1
2.2.2.2
100:1
Issue 02 (2011-09-10)

92

Check the encapsulation type of the PW.

<HUAWEI> display mpls l2vpn connection interface GigabitEthernet 8/0/0.13
conn-type: remote
local vc state:
up
remote vc state:
up
local ce-id:
1
local ce name:
ce1
remote ce-id:
2
intf(state,encap):
GigabitEthernet8/0/0.13(up,ethernet)
peer id:
2.2.2.2
route-distinguisher:
100:1
local vc label:
179222
remote vc label:
228373
tunnel policy:
default
primary or secondary:
primary
forward entry exist or not: true
forward entry active or not:true
manual fault set or not:
not set
AC OAM state:
up
BFD for PW session index:
-BFD for PW state:
invalid
BFD for LSP state:
true
Local C bit is not set
Remote C bit is not set
tunnel type:
lsp
tunnel id:
0x4008018
The PW can be negotiated only when the encapsulation types of the PW and VPN instance are
the same. If the encapsulation types of the PW and VPN instance are the same but the fault
persists, contact Huawei technical support personnel.
----End

Relevant Alarms
None.
Relevant Logs
None.
3.4 The VC Cannot Be Up When a Huawei Device

Communicates with a Non-Huawei Device Through
Kompella VLL
This section provides a step-by-step troubleshooting procedure for the fault that the VC cannot
be Up when a Huawei device communicates with a non-Huawei device through Kompella VLL.
3.4.1 Common Causes

Issue 02 (2011-09-10)

93

default-offset of a non-Huawei device is 1 and cannot be configured. When a Huawei

device communicates with the non-Huawei device, default-offset of the Huawei device
needs to be configured as 1 and the CE ID cannot be 0.
The ignore-mtu-match command is not configured in the MPLS-L2VPN instance view.

NOTE
Procedure
Step 1 Check that the ignore-mtu-match command is configured in the MPLS-L2VPN instance view.
If the ignore-mtu-match command is not configured, configure this command.
If the ignore-mtu-match command has already been configured, go to Step 2.
NOTE
After using this command, when a Huawei device communicates with a non-Huawei device through
Kompella VLL, they will not negotiate the MTUs.
Step 2 Check that default-offset of the Huawei device is 1.

#
#
return
If default-offset of the Huawei device is not 1, set it to 1. If default-offset of the Huawei device
is 1 but the fault persists, contact Huawei technical personnel.
----End

Relevant Alarms
None.
Relevant Logs
None.

Issue 02 (2011-09-10)

94

3.5.1 VC Under the Interface Is Missing After the Link Layer

Protocol Changes
Fault Symptom
The configuration is as follows:
# Configure MPLS L2VC on an interface on PE that connects the AC. The VC ID is 100.
[PE-Pos4/0/0] mpls l2vc 1.1.1.8 100
# View the configuration of the interface.

[PE-Pos4/0/0] display this
#
interface Pos4/0/0
link-protocol fr
mpls l2vc 1.1.1.8 100
#
return
# This interface has a VC. The VC ID is 100.

[PE-Pos4/0/0] display mpls l2vc interface pos 4/0/0
*client interface
: Pos4/0/0 is down
session state
: down
AC state
: down
VC state
: down
VC ID
: 100
VC type
: fr
destination
: 1.1.1.8
local group ID
: 0
remote group ID
: 0
local VC label
: 146433
remote VC label
: 0
local AC OAM State
: up
local PSN State
: up
local forwarding state : not forwarding
BFD for PW
: unavailable
manual fault
: not set
active state
: active
forwarding entry
: not exist
link state
: down
local VC MTU
: 4470
remote VC MTU
: 0
local VCCV
: Disable
remote VCCV
: none
local control word
: disable
remote control word : none
tunnel policy name
: -traffic behavior name : -PW template name
: -primary or secondary
: primary
VC tunnel/token info
: 0 tunnels/tokens
create time
: 0 days, 0 hours, 3 minutes, 24 seconds
up time
last change time
VC last up time
: 2009/04/07 16:19:26
VC total up time
# Another interface on the PE also has a VC. The VC ID is also 100, whose link layer protocol
is HDLC.
*client interface
: Pos4/1/0 is down
session state
: down
AC state
: down
VC state
: down
VC ID
: 100
VC type
: hdlc
Issue 02 (2011-09-10)

95

destination
local group ID
local VC label
local AC OAM State
local PSN State
local forwarding state
BFD for PW
manual fault
active state
forwarding entry
link state
local VC MTU
local VCCV
remote VCCV
local control word
tunnel policy name
traffic behavior name
PW template name
primary or secondary
VC tunnel/token info
create time
up time
last change time
VC last up time
:
VC total up time
:
: 2.2.2.8
: 0
remote group ID
: 0
: 146433
remote VC label
: 0
: up
: up
: not forwarding
: unavailable
: not set
: active
: not exist
: down
: 4470
remote VC MTU
: 0
: Disable
: none
: disable
remote control word : none
: -: -: -: primary
: 0 tunnels/tokens
2009/04/07 16:19:26
# Change the link layer protocol of POS 4/0/0 to HDLC.

[PE-Pos4/0/0] link-protocol hdlc
# Re-check POS 4/0/0 and find that no VC exists.

# Check all interfaces on PE and find that only one VC is left. This VC is on POS 4/1/0 whose
link layer protocol is HDLC.
[PE] display mpls l2vc
Total ldp vc : 1
0 up
1 down
*client interface
: Pos4/1/0
session state
: down
AC status
: down
VC state
: down
VC ID
: 100
VC type
: hdlc
destination
: 2.2.2.8
local VC label
: 146433
remote VC label
: 0
control word
: disable
forwarding entry
: not exist
local group ID
: 0
manual fault
: not set
active state
: active
link state
: down
local VC MTU
: 4470
remote VC MTU
: 0
tunnel policy name
: -traffic behavior name: -PW template name
: -primary or secondary : primary
create time
up time
last change time
VC last up time
: 2009/04/07 16:19:26
VC total up time
Fault Analysis
An interface (POS 4/1/0 for example) on a PE has an HDLC-type PW with the PW ID as 100,
and you change the link layer protocol of another interface (POS 4/0/0 for example) to HDLC.
Issue 02 (2011-09-10)

96

Then the system will delete the PW under POS 4/0/0 automatically. The reason is that the two
PWs have the same VC ID and the same VC type.
Procedure
Step 1 If you need to change the link layer protocol of a VC, ensure that the changed PW ID and VC
type are not the same as those of VCs on other interfaces of the same device.
----End
Summary
The combination of VC ID and VC type must be unique on the same device.
If a VC changes its link protocol type and this causes a conflict with other VCs, the VC will be
automatically deleted.
3.5.2 Both the Session and the AC Are Up, But the VC Cannot Be
Up
Fault Symptom
Figure 3-3 Networking diagram
PE1
GE1/0/0
10.1.1.2/24
PE2
GE2/0/0
100.1.1.2/24
GE2/0/0
100.1.1.1/24
GE1/0/0
10.1.1.1/24
GE1/0/0
10.1.1.1/24
GE1/0/0
10.1.1.2/24
CE1
CE2
As shown in Figure 3-3, the VC cannot go Up after Martini VLL is configured, and all
parameters about the remote end are 0s, namely, invalid values. Check the session and the AC,
and find both of them are Up.
Fault Analysis
Use the display mpls l2vc vc-id command on the PE to check whether the MTU values at both
ends are consistent. For example:
# Check the MTU value of the GE interface on PE1.
[PE1-GigabitEthernet1/0/0] display mpls l2vc 100
total LDP VC : 1
0 up
1 down
*client interface
session state
Issue 02 (2011-09-10)
: GigabitEthernet1/0/0
: up

97

AC status
:
VC state
:
VC ID
:
VC type
:
destination
:
local VC label
:
control word
:
forwarding entry
:
local group ID
:
manual fault
:
active state
:
link state
:
local VC MTU
:
tunnel policy name
:
PW template name
:
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
up
down
100
ethernet
2.2.2.2
146433
remote VC label
disable
not exist
0
not set
active
down
80
remote VC MTU
--pwt1
primary
0 days, 0 hours, 18 minutes,
2009/04/07 16:19:26
: 0
: 120
44 seconds
37 seconds
37 seconds
37 seconds
# View the MTU value of the GE interface on PE2.

total LDP VC : 1
0 up
1 down
*client interface
:
session state
:
AC status
:
VC state
:
VC ID
:
VC type
:
destination
:
local VC label
:
control word
:
forwarding entry
:
local group ID
:
manual fault
:
active state
:
link state
:
local VC MTU
:
tunnel policy name
:
PW template name
:
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
up
up
down
100
ethernet
1.1.1.1
146433
remote VC label
disable
not exist
0
not set
active
down
120
remote VC MTU
--pwt1
primary
2009/04/07 16:19:26
: 0
: 80
44 seconds
37 seconds
37 seconds
37 seconds
The display shows that the MTU value of the local end is not consistent with that of the remote
end, which leads to the parameter negotiation failure.
Modify the MTU value on either PE to make the MTU values consistent at both ends.
For example, change the MTU value of the interface on PE2 to make it consistent with that on
PE1.
[PE2-GigabitEthernet1/0/0] mtu 80
[PE2-GigabitEthernet1/0/0] shutdown
[PE2-GigabitEthernet1/0/0] undo shutdown
After the modification, the VC goes Up.

total LDP VC : 1
1 up
0 down
Issue 02 (2011-09-10)

98

*client interface
:
session state
:
AC status
:
VC state
:
VC ID
:
VC type
:
destination
:
local VC label
:
control word
:
forwarding entry
:
local group ID
:
manual fault
:
active state
:
link state
:
local VC MTU
:
tunnel policy name
:
PW template name
:
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
up
up
up
100
ethernet
1.1.1.1
146433
remote VC label
disable
exist
0
not set
active
up
80
remote VC MTU
---primary
2009/04/07 16:19:26
: 146433
: 80
12 seconds
5 seconds
5 seconds
5 seconds
Procedure
Step 1 Check whether the correct peer addresses are configured on PEs at both ends.
Step 2 Check whether the VC IDs at both ends are the same.
Step 3 Check whether the encapsulation types at both ends are the same.
Step 4 Check whether the control word is enabled or disabled at both ends. Both ends must enable or
disable the control word simultaneously.
Step 5 Check whether the MTU values are consistent at both ends.
Step 6 If inconsistency occurs, modify the MTU value on either end to ensure consistency.
Step 7 Use the shutdown command and then the undo shutdown command on the modified interface.
----End
Summary
PWE3 extends Martini interface parameters. Some of them must be supported, and others need
not be supported. Some of them must be matched while others need not match during the
negotiation.
The following lists the Martini interface parameters.
Issue 02 (2011-09-10)
Code
Length
Description
0x01
Interface MTU in octets
0x02
Maximum Number of concatenated ATM cells
0x03
up to 82
Optional Interface Description string
0x04
CEM [8] Payload Bytes

99

Code
Length
Description
0x05
CEM options
The following shows the PWE3 interface parameters.

Code
Length
Description
0x01
Interface MTU in octets
0x02
Maximum Number of concatenated ATM cells
0x03
Up to 82
Optional Interface Description string
0x04
CEP/TDM Payload Bytes
0x05
CEP options
0x06
Requested VLAN ID
0x07
CEP/TDM bit-rate
0x08
Frame-Relay DLCI Length
0x09
Fragmentation indicator
0x0A
FCS retention indicator
0x0B
4/8/12
TDM options
0x0C
VCCV parameter
Items from 0x06 to 0x0C are extended in PWE3.

When configuring interface parameters, note the following:
l
The same MTU must be specified for the Ethernet interface; otherwise, the PW cannot be
Up.
In ATM cell (0x0003 ATM transparent cell transport, 0x0009 ATM n-to-one VCC cell
transport and 0x000A ATM n-to-one VPC cell transport) mode, the maximum ATM cell
number must be sent to the peer in order to inform the peer how many cells it can handle
at a time. When the remote end encapsulates packets, this number should not be exceeded.
Inconsistency of the cell number at both ends does not affect the status of a PW.
Fragmentation and ATM cell have the same handling mode. The configuration of
fragmentation and ATM cell handling mode is optional and may not be consistent at both
ends. The local end only informs the remote end whether it can perform reassembly. The
remote end decides whether to fragment packets according to the packet size and its
fragmentation capability. The fragmentation capability does not affect the status of a PW,
and it is not necessary to be the same at both ends.
VCCV processing is similar to ATM cell and fragmentation capability. The VCCV
configuration is optional. The local end uses VCCV to inform the remote end of its VCCV
capability. When performing VCCV, the peer chooses a path (CC) and a method (CV)
Issue 02 (2011-09-10)

100

according to the configuration at both ends. VCCV does not affect the status of a PW, and
is not required consistent at both ends.
l
The Request VLAN ID is used to inform the peer of its capability. During the forwarding,
the remote end is required to insert a VLAN ID on its Layer 2 frame header. Other means
can also be used. This configuration is optional. If the Request VLAN ID is carried, the
VLAN IDs can be different at both ends.
3.5.3 Ethernet and ATM are interconnected and the VC Is Up, But
the Ping Between CEs Fails
Fault Symptom
Figure 3-4 Networking diagram of L2VPN in which Ethernet and ATM are connected
PE1
Backbone
GE1/0/0
GE1/0/0
PE2
ATM1/0/0
ATM1/0/0
CE2
CE1
As shown in Figure 3-4, Ethernet and ATM are interconnected. After L2VPN is configured to
support heterogeneous transport, the VCs at both ends are Up, but the ping between CEs fails.
Fault Analysis
Check and ensure that the IP address of the two CEs is on the same network segment.
Use the display local-ce mac command on the PE, and use the display arp command on the
CE to check whether the ARP entries of the Ethernet link are set up successfully.
If ARP entries are not set up successfully, run the local-ce ip command, the local-ce mac
command, or the local-ce mac broadcast command on the PE. In this manner, the IP address
and the MAC address of the Ethernet interface on the CE can be configured on the PE, and MAC
broadcasting function can be enabled.
For detailed configuration, refer to heterogeneous transport in L2VPN described in the Chapter
"MPLS L2VPN Configuration" in the HUAWEI NetEngine80E/40E Router Configuration
Guide - VPN.
For ARP entries of the ATM link, you can use one of the following methods:
l
Use INARP to generate MAP dynamically. Figure 3-5 shows an example to configure IP
addresses. The configuration is as follows.
[PE2] interface atm1/0/0
[PE2-Atm1/0/0] pvc 100/200
Issue 02 (2011-09-10)

101

[PE2-atm-pvc-Atm1/0/0-100/200]
[PE2-atm-pvc-Atm1/0/0-100/200]
[CE2] interface atm1/0/0
[CE2-Atm1/0/0] pvc 100/200
[CE2-atm-pvc-Atm1/0/0-100/200]
[CE2-atm-pvc-Atm1/0/0-100/200]
map ip inarp broadcast

ip address 10.1.1.1 255.255.255.0
map ip inarp broadcast
ip address 10.1.1.2 255.255.255.0
Figure 3-5 Networking diagram of IP addressing
PE1
GE1/0/0
10.1.1.2/24
PE2
Backbone
GE1/0/0
10.1.1.1/24
ATM1/0/0
10.1.1.1/24
ATM1/0/0
10.1.1.2/24
CE1
CE2
The static MAP is used. Configure the map ip peer-ce-address broadcast command or the
map ip default broadcast command in the PVC view of the ATM interfaces at both ends
of the AC.
For example:
[PE2] interface atm1/0/0
[PE2-Atm1/0/0] pvc 100/200
[PE2-atm-pvc-Atm1/0/0-100/200]
[PE2-atm-pvc-Atm1/0/0-100/200]
[CE2] interface atm1/0/0
[CE2-Atm1/0/0] pvc 100/200
[CE2-atm-pvc-Atm1/0/0-100/200]
[CE2-atm-pvc-Atm1/0/0-100/200]
map ip 10.1.1.2 broadcast

ip address 10.1.1.1 255.255.255.0
map ip 10.1.1.1 broadcast
ip address 10.1.1.2 255.255.255.0
Procedure
Step 1 Check whether the IP address of CE at both ends is on the same network segment.
Step 2 Run the display local-ce mac command on the PE, and run the display arp command on the
CE to check whether ARP entries of the Ethernet link are set up successfully.
Step 3 If ARP entries are not set up successfully, configure an IP address and MAC address for the
Ethernet interface at the AC side and enable MAC broadcasting on the PE. For the ATM link,
use INARP to generate MAP dynamically or use the static MAP.
----End
Summary
In the application of heterogeneous transport, if the VC is Up but the ping between CEs fails,
the cause is often the configuration error.
You should perform configuration according to the link type to ensure that ARP entries can be
generated correctly.
Issue 02 (2011-09-10)

102

3.5.4 CEs Cannot Communicate by Using the Accessing Mode of

VLAN
Fault Symptom
CEs adopt the accessing mode of VLAN. After the VLAN ID is changed, CEs on two ends
cannot communicate.
Fault Analysis
To modify the VLAN ID, you need to modify VC IDs of the AC interfaces along the packetsending direction in turn. To validate the modification, run the shutdown command and then
the undo shutdown command on each VLAN interface.
Procedure
Step 1 Use the vlan-type dot1q command on the AC interfaces along CE-to-PE direction, and then
PE-to-CE direction to modify the VLAN ID.
Step 2 Use the shutdown command to disable the AC interfaces.
Step 3 Use the undo shutdown command to enable the AC interfaces.
----End
Summary
When the VLAN access is adopted between CE and PE, the minimum VLAN IDs of interfaces
on both ends of the AC that the packet passes by must be the same. Otherwise, the packet cannot
be forwarded normally.
The minimum VLAN IDs of the CE interfaces on both ends of the tunnel can be different.
3.5.5 CEs Cannot Access Each Other Though the Static VC Is Up

Fault Symptom
After the static VC is configured, the static VC is Up. CEs, however, CEs cannot access each
other.
For example:
[PE1] display mpls static-l2vc
Total svc connections: 1, 1 up, 0 down
*Client Interface
: GigabitEthernet2/0/1 is up
AC Status
: up
VC State
: up
VC ID
: 0
VC Type
: ethernet
Destination
: 2.2.2.2
Transmit VC Label
: 200
Receive VC Label
: 100
Control Word
: Disable
VCCV Capability
: alert lsp-ping bfd
Tunnel Policy Name
: -Traffic Behavior
: -PW Template Name
: -Main or Secondary
: Main
Issue 02 (2011-09-10)

103

Create time
UP time
Last change time
VC last up time : 2008/07/24 12:31:31
VC total up time: 0 days, 2 hours, 12 minutes, 51 seconds
CKey
: 6
NKey
: 3
Fault Analysis
Check the label of the static VC on the remote PE:
[PE2] display mpls static-l2vc
Total svc connections: 1, 1 up, 0 down
*Client Interface
: GigabitEthernet1/0/1 is up
AC Status
: up
VC State
: up
VC ID
: 0
VC Type
: ethernet
Destination
: 1.1.1.1
Transmit VC Label
: 200
Receive VC Label
: 100
Control Word
: Disable
VCCV Capability
: alert lsp-ping bfd
Tunnel Policy Name
: -Traffic Behavior
: -PW Template Name
: -Main or Secondary
: Main
Create time
UP time
Last change time
VC last up time : 2008/07/24 12:31:31
VC total up time: 0 days, 2 hours, 12 minutes, 51 seconds
You can see that the label configuration on the local PE is different from that on the remote PE.
CEs can communicate after the following configuration:
[PE1-GigabitEthernet2/0/1] mpls static-l2vc destination 2.2.2.2 transmit-vpn-label
100 receive-vpn-label 200
Procedure
Step 1 Delete the static VC on one end and reconfigure it.
----End
Summary
When the label of the static VC is incorrect, the data cannot be forwarded normally even though
the VC is Up. In this case, you should pay attention to the consistency of labels at both ends of
a VC.
When configuring the static VC, note the following:
l
The local transmit-vpn-labe is the same as the remote receive-vpn-label.
The local receive-vpn-label is the same as the remote transmit-vpn-label.
Issue 02 (2011-09-10)

104

3.5.6 Large Packets Are Lost in the Transmission Between CEs at

Both Ends of L2VPN
Fault Symptom
After an L2VPN is set up between CEs, some large packets are lost in the transmission.
Fault Analysis
The packets can be transmitted between CEs, but some may be lost. The cause may be the
fragmentation, which occurs when the MTUs of the outgoing interfaces that packets pass by are
smaller than the MTU of the source interface.
Procedure
Step 1 Use the display interface command on the source interface to check the MTU.
Step 2 Use the display interface command on the PEs that packets pass by to check whether there are
outgoing interfaces whose MTUs is smaller than the MTU of the source interface.
Step 3 Use the mtu command in the AC interface view on CE or in the outgoing interface view on PE
to increase the MTU value, and thus ensure the packet sent by CE is not fragmented.
----End
Summary
When CEs are connected through the L2VPN, the sent packet passing through PEs cannot be
fragmented. Otherwise, the packet cannot be received normally.
3.5.7 Failed to Establish the MPLS LDP Session Between PEs When
Using RIP-1 in the L2VPN Backbone Network
Fault Symptom
Figure 3-6 Networking diagram of the L2VPN backbone adopting RIP as IGP
Loopback0
1.1.1.1/32
Loopback0
2.2.2.2/32
POS2/0/0
POS2/0/0
100.1.1.1/24 100.1.1.2/24
PE-A
POS1/0/0
POS1/0/0
POS1/0/0
10.1.1.1/24
POS1/0/0
10.1.1.2/24
CE-A
Issue 02 (2011-09-10)
POS3/0/0
1.1.2.3/16
PE-B
POS3/0/0
1.1.2.4/16
CE-B

105

NOTE
IGP is short for the Interior Gateway Protocol.
After the L2VPN backbone network running RIP-1 advertises the local loopback0 address and
the interface IP address, the MPLS LDP session between PEs cannot be set up.
The prompt on PE-A is as follows:
Del Session : EncdecEncode ldp notify msg failure.
Check the MPLS LDP session on PE-A. The display is as follows:

[PE-A] display mpls ldp session
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
-----------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
-----------------------------------------------------------------------------2.2.2.2:0
NonExistent
Passive
0/0
The prompt on PE-B is as follows:

Del Session : Tcp connection down
Check the MPLS LDP session on PE-B. The display is as follows:

[PE-A] display mpls ldp session
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
-----------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
-----------------------------------------------------------------------------1.1.1.1:0
Initialized
Active
0/0
Fault Analysis
Check the routing table on PE-B. The display is as follows:
[PE-B] display ip routing-table
Route Flags: R - relay, D - download to fib
-----------------------------------------------------------------------------Routing Tables: Public
Destinations : 10
Routes : 10
Destination/Mask
Proto Pre Cost
NextHop
Interface
1.0.0.0/8
RIP
100 1
100.1.1.1
Pos2/0/0
1.1.0.0/16 Direct 0
0
1.1.2.3
Pos3/0/0
1.1.2.3/32 Direct 0
0
127.0.0.1
InLoopBack0
1.1.2.4/32 Direct 0
0
1.1.2.4
Pos3/0/0
2.2.2.2/32 Direct 0
0
127.0.0.1
InLoopBack0
100.1.1.0/24 Direct 0
0
100.1.1.2
Pos2/0/0
100.1.1.2/32 Direct 0
0
127.0.0.1
InLoopBack0
127.0.0.0/8
Direct 0
0
127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
127.0.0.1
InLoopBack0
RIP-1 can identify only the route of the natural network segment such as class A, B, and C.
In the routing table of PE-B, there are two routes to peer 1.1.1.1.
l
The IP address 1.0.0.0/8 learned by RIP-1.
The IP address 1.1.0.0/16 directly connected with PE-B.
Issue 02 (2011-09-10)

106

According to the "longest match" rule, the packet is sent to POS 3/0/0 whose IP address is
1.1.0.0/16. In the network segment connected with POS 3/0/0, the loopback address 1.1.1.1/32
does not exist. Therefore, the MPLS LDP session cannot be set up.
Procedure
Step 1 Replace RIP-1 with RIP-2 to advertise the 32-bit loopback address. This address serves as the
MPLS LDP session address on the PE.
----End
Summary
RIP-1 can only identify the route of the natural network segment such as class A, B, and C.
Therefore, RIP-2 should be adopted to advertise the 32-bit loopback address of PE.
Issue 02 (2011-09-10)

107

4 PWE3 Troubleshooting
PWE3 Troubleshooting
About This Chapter

This chapter describes common causes of PWE3 faults and provides the corresponding
4.1 The PW Cannot Be Up
procedure for the fault that the PW of PWE3 cannot be Up.
Issue 02 (2011-09-10)

108

4.1 The PW Cannot Be Up

procedure for the fault that the PW of PWE3 cannot be Up.
4.1.1 Common Causes

l
The VC IDs of both ends of the VC are different.
The control word configuration of both ends of the VC are different.
The LDP session is not Up.
The tunnel policy is incorrectly configured so that the TE tunnel is not adopted as the public
network tunnel.
The tunnel on the local or remote end is not Up.

The VC cannot be Up after Martini VLL is configured.
Issue 02 (2011-09-10)

109

Figure 4-1 Troubleshooting flowchart for the VC of Martini VLL failing to be Up

A VC of Martini
VLL cannot be
Up
Encapsulation
types of both ends
the same?
No
Fault rectified?
End
Yes
End
No
Yes
MTUs of
both ends the
same?
No
Fault rectified?
No
Yes
VC IDs of both
ends the same
No
Fault rectified?
Yes
End
No
Yes
Control
words of both ends
the same
No
Fault rectified?
Yes
End
No
Yes
No
LDP session
is Up?
Fault rectified?
Yes
End
No
Yes
Tunnel is Up?
No
Fault rectified?
Yes
End
No
Yes
AC interfaces
are Up?
Yes
Yes
No
Fault rectified?
Yes
End
No
Seek technical
support
Issue 02 (2011-09-10)

110


NOTE
Procedure
Run the display mpls l2vc vc-id command to check VC information.
total LDP VC : 1
1 up
*client interface
:
session state
:
AC status
:
VC state
:
VC ID
:
VC type
:
destination
:
local VC label
:
control word
:
forwarding entry
:
local group ID
:
manual fault
:
active state
:
link state
:
local VC MTU
:
tunnel policy name
:
PW template name
:
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
0 down
up
up
up
102
VLAN
2.2.2.2
146433
remote VC label
: 146432
disable
exist
0
not set
active
up
1500
remote VC MTU
: 1500
---primary
2010/02/17 08:23:07
If the two ends are configured with different encapsulation types or MTUs, change the
encapsulation type or MTU of one end to be the same as that of the other end.
go to Step 2.
NOTE
MTU.
Step 2 Check that the VC IDs of both ends of the VC are the same.
total LDP VC : 1
1 up
*client interface
session state
AC status
VC state
VC ID
VC type
destination
local VC label
control word
Issue 02 (2011-09-10)
:
:
:
:
:
:
:
:
:
0 down
up
up
up
102
VLAN
2.2.2.2
146433
remote VC label
disable

: 146432
111

forwarding entry
:
local group ID
:
manual fault
:
active state
:
link state
:
local VC MTU
:
tunnel policy name
:
PW template name
:
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
exist
0
not set
active
up
1500
remote VC MTU
: 1500
---primary
2010/02/17 08:23:07
If the VC IDs of both ends of the VC are different, change the VC ID of one end to be the same
as that of the other end.
If the VC IDs of both ends of the VC are the same but the fault persists, go to Step 3.
NOTE
A VC can be Up only when the VC IDs of both ends of the VC are the same.
Step 3 Check that the CWs configuration of both ends of the VC are the same.
total LDP VC : 1
1 up
*client interface
:
session state
:
AC status
:
VC state
:
VC ID
:
VC type
:
destination
:
local VC label
:
control word
:
forwarding entry
:
local group ID
:
manual fault
:
active state
:
link state
:
local VC MTU
:
tunnel policy name
:
PW template name
:
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
0 down
up
up
up
102
VLAN
2.2.2.2
146433
remote VC label
: 146432
disable
exist
0
not set
active
up
1500
remote VC MTU
: 1500
---primary
2010/02/17 08:23:07
If the CWs configuration of both ends of the VC are different, change the VC ID of one end to
be the same as that of the other end.
If the CWs configuration of both ends of the VC are the same but the fault persists, go to Step
4.
NOTE
A VC can be Up only when the CWs of both ends of the VC are the same.
Step 4 Check that the LDP session between the two ends is Up.
total LDP VC : 1
1 up
Issue 02 (2011-09-10)
0 down

112

*client interface
:
session state
:
AC status
:
VC state
:
VC ID
:
VC type
:
destination
:
local VC label
:
control word
:
forwarding entry
:
local group ID
:
manual fault
:
active state
:
link state
:
local VC MTU
:
tunnel policy name
:
PW template name
:
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
up
up
up
102
VLAN
2.2.2.2
146433
remote VC label
: 146432
disable
exist
0
not set
active
up
1500
remote VC MTU
: 1500
---primary
2010/02/17 08:23:07
If the LDP session is Down, see "An LDP Session Is Down" to locate the fault and then turn the
LDP session Up.
If the LDP session is Up but the fault persists, go to Step 5.
NOTE
A VC can be set up only when the LDP session is Up.
Step 5 Check whether the PW has selected a tunnel.

Run the display mpls l2vc vc-id command.
l Check the VC tunnel/token info field in the command output. If VC tunnel/token info is
displayed as 0 tunnels/tokens, it indicates that no tunnel is selected by a PW.
l Check the tunnel policy name field in the command output.
If tunnel policy name is displayed as "-", it indicates that an LDP LSP is used as the
tunnel for a PW or no tunnel policy is configured. An MPLS TE tunnel can be used for
a PW only after a tunnel policy is configured.
If tunnel policy name is not displayed as "-", it indicates that a tunnel policy is adopted.
In this case, you can run the display this command in the tunnel policy view to view the
tunnel policy configuration.
#
tunnel-policy p1
#
Step 6.
NOTE
Issue 02 (2011-09-10)

113

Run the display mpls l2vc vc-id command on both ends of the VC to check whether the AC
status field is displayed as Up.
NOTE
A VC can be Up only when the AC interfaces on both ends of the VC are Up.
----End

Relevant Alarms
None.
Relevant Logs
None.

4.2.1 PW Attributes Cannot Be Changed by Using the reset pw
Command
Fault Symptom
After a PW is configured on a PE, change PW attributes.
Use the reset pw pw-template pw-template-name command or the reset pw pw-id pw-type
command. You find that PW attributes are unchanged.
# Check the configuration of the PW template on PE.
[PE] display pw-template pwt1
PW Template Name : pwt1
PeerIP
: 1.1.1.1
Tnl Policy Name : -CtrlWord
: Disable
MTU
: 1500
Max Atm Cells
: 28
ATM Pack Overtime: 1000
Seq-Number
: Disable
TDM Encapsulation Number: 32
Jitter-Buffer
: 20
Idle-Code
: ff
Rtp-Header
: Disable
VCCV Capability : alert lsp-ping bfd
Issue 02 (2011-09-10)

114

Behavior Name
Total PW
: -: 1, Static PW : 0, LDP PW : 1
# Configure a PW by applying the PW template.

[PE-Atm2/1/0.100] mpls l2vc pw-t pwt1 2.2.2.2 100
# View the PW configuration.

[PE-Atm2/1/0.100] display mpls l2vc 100
total LDP VC : 1
0 up
1 down
*client interface
:
session state
:
AC status
:
VC state
:
VC ID
:
VC type
:
destination
:
local VC label
:
control word
:
forwarding entry
:
local group ID
:
manual fault
:
active state
:
link state
:
local VC MTU
:
tunnel policy name
:
PW template name
:
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
Atm2/1/0.100
down
up
down
100
atm aal5 sdu
2.2.2.2
146433
remote
disable
not exist
0
not set
active
down
1500
remote
--pwt1
primary
0 days, 0 hours, 18
0 days, 0 hours, 12
0 days, 0 hours, 12
2009/04/07 16:19:26
0 days, 0 hours, 12
VC label
: 0
VC MTU
: 0
minutes, 44 seconds
minutes, 37 seconds
minutes, 37 seconds
minutes, 37 seconds
# Specify a new peer address for the PW in the PW template.

[PE] pw-template pwt1
[PE-pw-template-pwt1] peer-address 3.3.3.3
Info: The attribute of this PW template has been modified, please use PW restart
command to update PW's attribute
According to the prompt, do as follows.

[PE-pw-template-pwt1] return
# Reset the PW.

<PE> reset pw 100 atm-aal5-sdu
# View the output, and find that the peer IP address of the PW is unchanged.
<PE> display mpls l2vc 100
total LDP VC : 1
0 up
*client interface
session state
AC status
VC state
VC ID
VC type
destination
local VC label
control word
forwarding entry
local group ID
manual fault
active state
Issue 02 (2011-09-10)
:
:
:
:
:
:
:
:
:
:
:
:
:
1 down
Atm2/1/0.100
down
up
down
100
atm aal5 sdu
2.2.2.2
146433
remote VC label
disable
not exist
0
not set
active

: 0
115

link state
:
local VC MTU
:
tunnel policy name
:
PW template name
:
create time
:
up time
:
last change time
:
VC last up time
:
VC total up time
:
down
1500
remote
--pwt1
primary
0 days, 0 hours, 18
0 days, 0 hours, 12
0 days, 0 hours, 12
2009/04/07 16:19:26
0 days, 0 hours, 12
VC MTU
: 0
minutes, 44 seconds
minutes, 37 seconds
minutes, 37 seconds
minutes, 37 seconds
# Reset the PW template.

<PE> reset pw pw-template pwt1
# View the output, and find that the peer IP address of the PW still does not change.
Total ldp vc : 1
0 up
1 down
*Client Interface
: Atm2/1/0.100
Session State
: down
AC Status
: up
VC State
: down
VC ID
: 1
VC Type
: atm aal5 sdu
Destination
: 2.2.2.2
Local VC Label
: 119811
Remote VC Label
: 0
Control Word
: Disable
Local VC MTU
: 1500 Remote VC MTU
: 0
Tunnel Policy Name
: -Traffic Behavior Name: -PW Template Name
: pwt1
Create time
UP time
Last change time
Fault Analysis
Some PW attributes can be configured by using the PW template or by using the CLI command.
However, the latter method has the higher priority.
If PW attributes are specified in the CLI, then those specified in the PW template are invalid.
The PW attributes do not change if the reset pw pw-template pw-template-name command or
the reset pw pw-id pw-type commands are run.
In this case, you can use the PW template to set PW attributes, rather than using the CLI
command. Do as follows:
# Specify the peer IP address in the PW template.
[PE] pw-template pwt1
[PE-pw-template-pwt1] peer-address 3.3.3.3
[PE-pw-template-pwt1] quit
# Apply the template to the PW.

[PE] interface atm 2/1/0.100
[PE-Atm2/1/0.100] mpls l2vc pw-t pwt1 100
# View the output, and find that the IP address of the PW peer is unchanged.
[PE-Atm2/1/0.100] display mpls l2vc 100
Total ldp vc : 1
0 up
1 down
*Client Interface
: Atm2/1/0.100
Session State
: down
Issue 02 (2011-09-10)

116

AC Status
: up
VC State
: down
VC ID
: 1
VC Type
: atm aal5 sdu
Destination
: 2.2.2.2
Local VC Label
: 119811
Remote VC Label
: 0
Control Word
: Disable
Local VC MTU
: 1500
Remote VC MTU
: 0
Tunnel Policy Name
: pwt1
Create time
UP time
Last change time
[PE-Atm2/1/0.100] return
<PE> reset pw 100 atm-aal5-sdu
# View the output, and find that the IP address of the PW peer changes.
Total ldp vc : 1
0 up
1 down
*Client Interface
: Atm2/1/0.100
Session State
: down
AC Status
: up
VC State
: down
VC ID
: 100
VC Type
: atm aal5 sdu
Destination
: 3.3.3.3
Local VC Label
: 119811
Remote VC Label
: 0
Control Word
: Disable
Local VC MTU
: 1500
Remote VC MTU
: 0
Tunnel Policy Name
: pwt1
Create time
UP time
Last change time
Procedure
Step 1 Create a PW template, and set PW attributes (especially those needing changes) on it.
Step 2 Apply the PW template to the PW.
Step 3 Run the reset pw pw-template pw-template-name command or the reset pw pw-id pw-type
command in the user view to modify PW attributes.
----End
Summary
The reset pw pw-template pw-template-name command or the reset pw pw-id pw-type
command can only change the attributes that are set by the PW template.
4.2.2 VPN Services Between Two PEs Are Unavailable

Fault Symptom
PWE3 internetworking is configured in a test, as shown in Figure 4-2.
Issue 02 (2011-09-10)

117

Figure 4-2 PWE3 internetworking
MPLS Backbone
Loopback0
1.1.1.9/32
Loopback0
2.2.2.9/32
POS2/0/0
100.1.1.1/24
POS1/0/0
100.1.1.2/24
PE1 GE1/0/0.1
P
PW
Loopback0
3.3.3.9/32
POS2/0/0
100.2.1.2/24
POS2/0/0
100.2.1.1/24
POS1/0/0
GE1/0/0.1
10.1.1.1/24
PE2
POS1/0/0
10.1.1.2/24
CE2
CE1
After the configuration, CE2 can receive data from CE1, but CE1 cannot receive data from CE2.
Fault Analysis
1.
Run the ping vc command to check whether the VC between the two PEs can normally
forward data. You can find that the VC between the two PEs can forward packets normally.
<PE1> ping vc ip-interworking 100 control-word remote 100
Reply: bytes=100 Sequence=1 time = 11 ms
--- FEC: FEC 128 PSEUDOWIRE (NEW). Type = ethernet, ID = 100 ping statistics--5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 4/5/11 ms
2.
Run the tracert command. You can find that CE2 can normally receive packets from CE1
and all packets sent by CE1 can reach PE1. This indicates that the fault occurs on the link
between PE1 and CE1.
3.
Run the display this command on GE 1/0/0.1 of PE1 to view the configuration of the AC
interface. You can find that the local-ce ip and local-ce mac commands are not used.
Procedure
Step 2 Run the interface interface-type interface-number command to enter the AC interface view of
PE1.
Step 3 Run the local-ce ip ip-address command to configure the IP address of the local CE interface,
or run the local-ce mac mac-address command to configure the MAC address of the local CE
interface.
Issue 02 (2011-09-10)

118

After the preceding configurations, the local CE can ping through the remote CE. The fault is
thus rectified.
----End
Summary
When configuring PWE3 internetworking, you need to run the local-ce ip command or the localce mac command to configure the MAC address or IP address for the CE interface if the AC
interface of the related PE is an Ethernet interface.
For PWE3 internetworking, a CE and a PE can directly negotiate with each other. When the AC
interface is an Ethernet interface, the negotiation between the CE and the PE is the process of
learning MAC addresses from each other. When PE1 sends packets to CE1, PE1 must know the
MAC address of the CE1 interface. You can run the local-ce mac command to configure the
address of the directly connected interface on PE1 as the MAC address of the CE1 interface.
When sending a packet, PE1 encapsulates the MAC address in the packet. You can also run the
local-ce ip command to configure the AC interface address of PE1 as the IP address of the CE1
interface. PE1 thus can learn the MAC address of the CE1 interface through the IP address.
4.2.3 Failed to Establish OSPF Neighborhood Between CEs

Fault Symptom
As shown in Figure 4-3, CE1 is dual-homed to PE1 and PE2; CE2 is dual-homed to PE3 and
PE4.
l
CE1 and CE2 are connected to PEs through Frame Relay (FR).
PWs are set up between PE1 and PE3, and between PE2 and PE4, using MPLS LSPs as
the tunnel.
When the path CE2 - PE3 - P - PE1 - CE1 fails, L2VPN traffic can be fast switched to the
backup path CE2 - PE4 - PE2 - CE1.
When the path CE2 - PE3 - P - PE1 - CE1 recovers, L2VPN traffic can be switched back
to this path.
Virtual Leased Line Fast Reroute (VLL FRR) symmetric networking is deployed on PEs; 128
sub-interfaces with different IP addresses are created on CEs. Open Shortest Path First (OSPF)
is run on CE1 and CE2 to advertise the IP addresses of the sub-interfaces to each other. The
problem is that the status of most neighborhood cannot be Full on CEs and CEs cannot
communicate.
Figure 4-3 Symmetric VLL FRR networking
PE1
P1
GE2/0/0
GE1/0/0
POS1/0/0
PE3
GE2/0/0
GE2/0/0
POS1/0/0
POS1/0/0
POS1/0/0
CE1
CE2
POS1/0/1
PE2
POS1/0/0
Issue 02 (2011-09-10)
P2
GE2/0/0
GE1/0/0
PE4
GE2/0/0
GE2/0/0

POS1/0/1
POS1/0/0
119

Fault Analysis
The MTU of Ethernet interfaces on CEs is set to 4470. The type of the links connecting PEs and
Ps are Ethernet and hence the maximum MTU is 1500. Therefore, when a large number OSPF
neighbors are configured on CEs, the size of an OSPF packet is larger than 1500. VLL does not
support packet fragmentation. Therefore, the large packets from CEs are discarded when they
are forwarded through the VLL between PEs and Ps. In this way, OSPF neighborhood cannot
be set up between CEs.
Procedure
Step 2 Run the interface interface-type interface-number.subinterface-number command to enter the
AC sub-interface view.
Step 3 Run the mtu mtu command to configure the MTU of the sub-interface.
Step 4 Run the shutdown command to close the current sub-interface.
Step 5 Run the undo shutdown command to start the current sub-interface.
After the preceding configurations, OSPF neighborhood can be established between CEs and
the fault is rectified.
----End
Summary
L2VPN does not support packet fragmentation. So, large packets sent from the CE to the PE
cannot be forwarded to the PSN side. When configuring VLL, you are recommended to set the
MTU value of the interface connecting the CE to the PE to 1500 by using the mtu command.
As a result, larger packets sent by the CE to the PE are fragmented first. The fragmented packets
can be correctly forwarded in the public network.
Issue 02 (2011-09-10)

120

5 L2VPN IP RAN Troubleshooting
L2VPN IP RAN Troubleshooting
About This Chapter

This chapter describes common causes of L2VPN IP RAN faults and provides the corresponding
5.1 Packets Are Lost or Duplicate Packets Are Received on an Integrated IP RAN with the
Networking of HVPLS + L3VPN/IP
procedure for the fault that packets are lost or duplicate packets are received on the CSG in an
IP RAN with the networking of HVPLS + L3VPN/IP.
5.2 Packets Are Lost, Duplicate Packets Are Received, or Traffic Is Interrupted After a Primary/
Secondary PW Switchover on a BTB IP RAN with the Networking of PWE3 + (VSI + L3VPN)
procedure for the fault that packets are lost, duplicate packets are received, or traffic is interrupted
on the CSG after a primary/secondary PW switchover is performed on a back-to-back (BTB) IP
RAN with the networking of PWE3 + (VSI + L3VPN).
5.3 Packets Are Lost or Traffic Is Interrupted on a BTB IP RAN with the Networking of HVPLS
+ L3VPN
procedure for the fault that packets are lost or traffic is interrupted on the CSG after a primary/
secondary PW switchover or switchback is performed on a BTB IP RAN with the networking
of HVPLS + L3VPN.
5.4 L2VPN Traffic Is Interrupted After AC Switchover on the IP RAN in PW Redundancy +
APS 1:1 Mode with TDM/ATM Base Stations
procedure for the fault that L2VPN traffic is interrupted after AC switchover on the IP RAN in
PW redundancy + APS 1:1 mode with TDM/ATM base stations.
5.5 Trouble Cases
Issue 02 (2011-09-10)

121

5.1 Packets Are Lost or Duplicate Packets Are Received on

an Integrated IP RAN with the Networking of HVPLS +
L3VPN/IP
procedure for the fault that packets are lost or duplicate packets are received on the CSG in an
IP RAN with the networking of HVPLS + L3VPN/IP.
5.1.1 Common Causes

l
The parameter ignore-standby-state is not configured when the VPLS PW is configured

on the SR or PE-AGG.
The primary and secondary PWs on the CSG are both enabled to receive packets.

After an IP RAN with the networking of HVPLS + L3VPN/IP is configured, packets are lost or
duplicate packets are received on the IP RAN.
Issue 02 (2011-09-10)

122

Figure 5-1 Troubleshooting flowchart for the fault that packets are lost or duplicate packets are
received on the IP RAN with the networking of HVPLS + L3VPN/IP
Packet loss or
duplicate packets
found on the IP
RAN (HVPLS)
Is the PW on the SR/PEAGG configured to ignore

the secondary state?
No
Configure the PW on the

SR/PE-AGG to ignore the
secondary state sent
from the peer
End
Disable this function

on the CSG
End
Yes
Are primary and

secondary PWs on the
CSG both enabled to
receive packets?
Yes
No
Seek technical
support

NOTE
Procedure
Step 1 Check fault symptoms.
l If packets are lost, go to Step 2.
l If duplicate packets are received, go to Step 3.
Step 2 Check that the parameter ignore-standby-state is configured when the VPLS PW is configured
on the SR or PE-AGG.
Run the display this command in the VSI-LDP view to check whether the parameter ignorestandby-state has been configured for the PW.
l If the parameter has not been configured, run the undo peer peer-address [ negotiation-vcid vc-id ] command in the VSI-LDP view to delete the PW. After that, run the peer peerIssue 02 (2011-09-10)

123

address [ negotiation-vc-id vc-id ] [ tnl-policy policy-name ] ignore-standby-state

command to create a new VPLS PW and configure it to ignore the secondary state sent from
the peer.
NOTE
l After the old VPLS PW is deleted, services will be temporarily interrupted until a new VPLS PW
is completely configured.
l In the scenario where PW redundancy in master/slave mode is configured, traffic will be switched
to the secondary PW if the primary PW becomes faulty. If the PW on the SR or PE-AGG is not
configured to ignore the secondary state sent from the CSG peer, the PW on the local end (local
PW for short) will not forward traffic. The local PW starts to forward traffic after the peer switches
from the secondary state to the primary state and sends the new state to the local end. During this
process, data packets are probably lost. To prevent this problem, configure ignore-standbystate when configuring a PW on the SR or PE-AGG. This enables the PW to ignore the secondary
state sent from the peer and allows the PW to remain in the forwarding state in the primary/
secondary PW switchover.
l If the parameter ignore-standby-state has been configured for the PW, go to Step 2.
Step 3 Check that the primary and secondary PWs on the CSG are not both enabled to receive packets.
Run the display this command in the view of the AC interface on the CSG to check whether
the mpls l2vpn stream-dual-receiving command has been run.
l If the mpls l2vpn stream-dual-receiving command has been run, run the undo mpls l2vpn
stream-dual-receiving command in the AC interface view to delete the configuration.
NOTE
The mpls l2vpn stream-dual-receiving command can only be run in a PWE3 L2VPN to prevent packet
loss during PW state synchronization. If an L2VPN uses H-VPLS, the mpls l2vpn stream-dualreceiving command cannot be run. This is because VPLS broadcast will cause a base station to receive
double data packets.
l If the primary and secondary PWs on the CSG are not both enabled to receive packets, go to
Step 3.
l Results of the preceding troubleshooting procedures
l Configuration files, log files, and alarm files of the device
----End

Relevant Alarms
None.
Relevant Logs
None.
Issue 02 (2011-09-10)

124

5.2 Packets Are Lost, Duplicate Packets Are Received, or

Traffic Is Interrupted After a Primary/Secondary PW
Switchover on a BTB IP RAN with the Networking of PWE3
+ (VSI + L3VPN)
procedure for the fault that packets are lost, duplicate packets are received, or traffic is interrupted
on the CSG after a primary/secondary PW switchover is performed on a back-to-back (BTB) IP
RAN with the networking of PWE3 + (VSI + L3VPN).
5.2.1 Common Causes

This fault is commonly caused in one of the following situations:
l
The PW on the PE-AGG is not configured to ignore the secondary state sent from the peer.
The primary and secondary PWs on the CSG are both enabled to receive packets.
No Spoke PW is configured between UPE1 and UPE2.
The downlink interface tracked by VRRP is not switched to a Layer 2 interface.
BFD used to monitor the primary and secondary PWs does not monitor the AC interface
status.

On a BTB IP RAN, packets are lost, duplicate packets are received, or traffic is interrupted after
primary/secondary PW switchover.
Issue 02 (2011-09-10)

125

Figure 5-2 Troubleshooting flowchart for the fault that packets are lost, duplicate packets are
received, or traffic is interrupted after primary/secondary PW switchover on a BTB IP RAN
Faults occur after
primary/secondar
y PW switchover
on a BTB IP RAN
Is the
PW on the PE-AGG
configured to ignore the
secondary state sent
from the peer?
No
Configure the PW on
the PE-AGG to ignore
the secondary state
sent from the peer
End
Disable this function

on the CSG
End
Configure BFD used

to check primary and
secondary PWs to
monitor the AC
interface
End
Configure a Spoke
PW
End
Yes
Are primary and
secondary PWs on the
CSG both enabled to
receive packets?
Yes
No
Does BFD used to

check primary and
secondary PWs
monitor the AC
interface?
No
Yes
No
Is a Spoke PW configured?
Yes
Seek technical
support

NOTE
Procedure
Issue 02 (2011-09-10)

126


l If duplicate packets are received, go to Step 4.
l If traffic is interrupted, go to Step 5.
Step 2 Check that the parameter ignore-standby-state is configured when the VPLS PW is configured
on the PE-AGG.
Run the display this command in the VSI-LDP view to check whether the parameter ignorestandby-state has been configured for the PW.
l If the parameter has not been configured, run the undo peer peer-address [ negotiation-vcid vc-id ] command in the VSI-LDP view to delete the PW. After that, run the peer peeraddress [ negotiation-vc-id vc-id ] [ tnl-policy policy-name ] ignore-standby-state
command to create a new VPLS PW and configure it to ignore the secondary state sent from
the peer.
NOTE
l After the old VPLS PW is deleted, services will be temporarily interrupted until a new VPLS PW
is completely configured.
l In the scenario where PW redundancy in master/slave mode is configured, traffic will be switched
to the secondary PW if the primary PW becomes faulty. If the PW on the PE-AGG is not configured
to ignore the secondary state sent from the peer, the PW on the local end (local PW for short) will
not forward traffic. The local PW starts to forward traffic after the peer switches from the secondary
state to the primary state and sends the new state to the local end. During this process, data packets
are probably lost. To prevent this problem, configure ignore-standby-state when setting a PW on
the PE-AGG. This enables the PW to ignore the secondary state sent from the peer and allows the
PW to remain in the forwarding state in primary/secondary PW switchover.
l If the parameter ignore-standby-state has been configured for the PW, go to Step 3.
Step 3 Check that BFD used to monitor the primary and secondary PWs is configured to monitor the
AC interface status.
Run the display bfd configurationpwinterfaceinterface-typeinterface-numberverbose
command on PE-AGG1 and PE-AGG2 to check whether the Bind Interface is an AC interface.
The parameter interface interface-type interface-number specifies an AC interface that is bound
to the PW.
<HUAWEI> display bfd configuration pw interface gigabitethernet 1/0/2.1 verbose
-------------------------------------------------------------------------------BFD Session Configuration Name : test
-------------------------------------------------------------------------------Local Discriminator
: 1
Remote Discriminator
: 1
BFD Bind Type
: PW(Master)
Bind Session Type
: Static
Bind Interface
: GigabitEthernet1/0/2.1
PW TTL Mode
: Auto
PW TTL
: Node
: UPE
Remote Peer
: 8.8.8.8
Encapsulation Type
: Vc Id
: Select Board
: Track Interface
: GigabitEthernet1/0/2.1
TOS-EXP
: 7
Local Detect Multi
: 3
Min Tx Interval (ms)
: 10
Min Rx Interval (ms)
: 10
WTR Interval (ms)
: Process PST
: Enable
Proc Interface Status : Disable
Bind Application
: L2VPN | OAM_MANAGER | MPLSFW
Session Description
: --------------------------------------------------------------------------------
l If it is not an AC interface, run the bfd cfg-name bind pw interface interface-type interfacenumber [ remote-peer remote-peer-address pw-ttl { auto-calculate | ttl-number } ] trackIssue 02 (2011-09-10)

127

interface command in the system view to configure the BFD session to monitor the primary
and secondary PWs and the AC interface status.
NOTE
BFD is required to monitor the AC interface status when it is checking PWs to ensure quick PW switchover
in the case of link failure between the PE-AGG and UPE; otherwise, packets will be lost during primary/
secondary PW switchover.
l If it is an AC interface, go to Step 6.
Step 4 Check that the primary and secondary PWs on the CSG are not both enabled to receive packets.
Run the display this command in the view of the AC interface on the CSG to check whether
the mpls l2vpn stream-dual-receiving command has been run.
l If the mpls l2vpn stream-dual-receiving command has been run, run the undo mpls l2vpn
stream-dual-receiving command in the AC interface view to delete the configuration.
NOTE
The mpls l2vpn stream-dual-receiving command can only be run in a PWE3 L2VPN to prevent packet
loss during PW state synchronization. If an L2VPN uses HVPLS, the mpls l2vpn stream-dualreceiving command cannot be run. This is because VPLS broadcast will cause a base station to receive
double data packets.
l If the primary and secondary PWs on the CSG are not both enabled to receive packets, go to
Step 6.
Step 5 Check that a Spoke PW is configured between UPEs or between PE-AGGs.
The following uses the Spoke PW between UPE1 and UPE2 as an example.
Run the display vsi [ name vsi-name ] [ verbose ] command on UPE1 and UPE2 to check if
there is a PW whose PW Type information is displayed as MEHVPLS.
l If such a PW is not found, run the peer peer-address [ negotiation-vc-id vc-id ] [ tnlpolicy policy-name ] upe ignore-standby-state command in the VSI-LDP view to configure
a Spoke PW. The command needs to be run on both UPE1 and UPE2 with the same
parameters being specified or configured.
NOTE
If no Spoke PW is configured, traffic will be interrupted because traffic uses the Spoke PW as a bypass after
primary/secondary PW switchover is performed.
l If a Spoke PW is configured, go to Step 6.

----End

Relevant Alarms
None.
Issue 02 (2011-09-10)

128

Relevant Logs
None.
5.3 Packets Are Lost or Traffic Is Interrupted on a BTB IP

RAN with the Networking of HVPLS + L3VPN
procedure for the fault that packets are lost or traffic is interrupted on the CSG after a primary/
secondary PW switchover or switchback is performed on a BTB IP RAN with the networking
of HVPLS + L3VPN.
5.3.1 Common Causes

l
The downlink interface tracked by VRRP is not switched to a Layer 2 interface.
No preemption delay is set for routers in the mVRRP backup group on the NPE or the
preemption delay is set too short.
On the NPE, the VRRP-capable interface is not associated with the service VRRP backup
group configured on it.

On a BTB IP RAN with the networking of HVPLS + L3VPN, packets are lost or traffic is
interrupted after a primary/secondary PW switchover or switchback.
Issue 02 (2011-09-10)

129

Figure 5-3 Troubleshooting flowchart for the fault that packets are lost or traffic is interrupted
after a primary/secondary PW switchover or switchback on a BTB IP RAN with the networking
of HVPLS and L3VPN
A fault occurs after
a PW switchover in
a BTB IP RAN
Is the AC interface on
the downlink tracked
by VRRP a Layer 2
interface?
No
Switch the physical

interface tracked by
VRRP to a Layer 2
interface
End
Yes
Is a preemption delay
configured for the
VRRP backup group
on NPE1?
No
Set the allowed

longest preemption
delay for the VRRP
backup group
End
Associate the
interface with the
VRRP backup group
End
Yes
Is the interface
associated with the
service VRRP backup
group on NPE1
No
Yes
Seek technical
support

NOTE
Procedure
l If traffic is interrupted, go to Step 2.
Step 2 Check that the downlink AC interface tracked by VRRP is a Layer 2 interface.
Issue 02 (2011-09-10)

130

Run the display this command on the AC interface on UPE1 and UPE2 to check whether the
portswitch command has been run on this interface.
l If the portswitch command has not been run, run the portswitch command in the AC
interface view to switch the interface to a Layer 2 interface.
NOTE
After VRRP is configured to track the interface status, master/backup switchover can be performed in the
VRRP backup group along with the primary/secondary PW switchover immediately after the link between
the PE-AGG and the UPE becomes faulty. VRRP monitors the protocol status on an interface. If the interface
is a Layer 3 interface, the protocol status remains Down because L2VPN is configured on the interface, and
the VRRP backup group status cannot be successfully negotiated. To address this problem, you need to
switch the physical interface tracked by VRRP to a Layer 2 interface. After that, the protocol status on the
interface changes to Up, and the VRRP backup group status can be successfully negotiated.
l If the downlink AC interface tracked by VRRP is a Layer 2 interface, go to Step 5.

Step 3 Check that a preemption delay is set for routers in the mVRRP backup group on NPE1.
On NPE1, run the display this command on the interface where the mVRRP backup group is
configured. The command output will show whether a preemption delay has been set with the
vrrp vrid preempt-mode timer delay command for routers in the mVRRP backup group.
l If no preemption delay is set or the set preemption delay is too short, run the vrrp vridvirtualrouter-idpreempt-modetimerdelay delay-value command on the same interface to set the
allowed longest delay for routers in the mVRRP backup group.
NOTE
After PE-AGG1 recovers from a fault, if VRRP switchback in the mVRRP backup group is faster than the
CSG's reselection of the primary PW or the spoke PW to reach PE-AGG1, traffic from the RNC to the NodeB
is forwarded to NPE1 and then to PE-AGG1 and after that no PW is available for it. To prevent this problem,
a VRRP switchback delay needs to be configured on NPE1 to allow a VRRP switchback only after a
corresponding PW is established and the PW switchback is performed.
l If the allowed longest preemption delay is configured for routers in the mVRRP backup
group, go to Step 4.
Step 4 On NPE1, check that the VRRP-capable interface is associated with the service VRRP backup
group configured on it.
On NPE1, run the display this command on the interface where a service VRRP backup group
is configured. The command output will show whether the direct-route track vrrp command
has been run to associate the interface with the group. If they are associated, the link cost of the
interface will change based on the VRRP status.
l If they are not associated, run the direct-route track vrrp vrid virtual-router-id degradecost cost command to associate the interface with the service VRRP backup group.
NOTE
In a VRRP backup group, IP addresses of the VRRP-capable interfaces on devices in the Master or Backup
state will be advertised to L3VPN. Configuring a preemption delay cannot ensure that VPN FRR switchback
on RSG1 is performed after VRRP switchback. After the direct-route track vrrp command is run to
associate an interface with a VRRP backup group, the interface adjusts the cost of the direct route in the
network segment to which the interface belongs based on the VRRP status, allowing a successful traffic
switchback after fault rectification.
l If they are associated, go to Step 5.

l Results of the preceding operation procedure
Issue 02 (2011-09-10)

131


----End

Relevant Alarms
None.
Relevant Logs
None.
5.4 L2VPN Traffic Is Interrupted After AC Switchover on

the IP RAN in PW Redundancy + APS 1:1 Mode with TDM/
ATM Base Stations
procedure for the fault that L2VPN traffic is interrupted after AC switchover on the IP RAN in
PW redundancy + APS 1:1 mode with TDM/ATM base stations.
5.4.1 Common Causes

l
No bypass PW is configured.

L2VPN traffic is interrupted after AC switchover on the IP RAN in PW redundancy + APS 1:1
mode with TDM/ATM base stations.
Issue 02 (2011-09-10)

132

Figure 5-4 Troubleshooting flowchart for the fault that L2VPN traffic is interrupted after AC
switchover on the IP RAN in PW redundancy + APS 1:1 mode with TDM/ATM base stations
Packet loss or duplicate packets
found on an IP RAN in PW
redundancy+APS 1:1 mode with
TDM/ATM BTSs
No
Is a bypass PW configured?
Configure a
bypass PW
End
Yes
Seek technical
support

NOTE
Procedure
Step 1 Check that a bypass PW is configured between RSG1 and RSG2.
Run the display mpls l2vc interface interface-type interface-number command on the AC
interface on RSG1 or RSG 2 to check whether there is a PW whose primary or secondary or
bypass information is bypass.
l If such a PW is not found, run the mpls l2vc { ip-address | pw-template pw-templatename } * vc-id [ group-id group-id | tunnel-policy policy-name | [ control-word | nocontrol-word ] | [ ip-interworking | ip-layer2 | raw | tagged ] ] * bypass command in the
AC interface view to create a bypass PW. The command needs to be run on both RSG1 and
RSG2 with the same parameters being specified or configured.
NOTE
If no bypass PW is configured, traffic will be interrupted because traffic should be directed to the bypass
PW after primary/secondary PW switchover is performed.
l If a bypass PW is configured, go to Step 2.

Issue 02 (2011-09-10)

133


----End

Relevant Alarms
None.
Relevant Logs
None.
5.5 Trouble Cases

5.5.1 Too Many Packets Are Lost Because ignore-standby-state Is
Not Configured in the peer Command
In an IPRAN with the networking of HVPLS + L3VPN, the parameter ignore-standby-state is
not configured in the peer command when a VPLS peer is configured. This will cause loss of a
great number of packets during primary/secondary PW switchover.
Fault Symptom
As shown in Figure 5-5, in the IPRAN with the networking of HVPLS + L3VPN/IP, the L2VPN
uses HVPLS (PWE3 accessing VPLS), and a primary PW and a secondary PW are configured
for PW redundancy in master/slave mode. During primary/secondary PW switchover, too many
packets are lost.
Figure 5-5 Networking diagram for the IPRAN (HVPLS + L3VPN)
H-VPLS(PWE3+VPLS)
SR1
RSG1
CSG
RNC
NodeB
SR2
L2VPN
Issue 02 (2011-09-10)
RSG2
L3VPN

134

Fault Analysis
1.
Run the display mpls l2vc interface interface-type interface-number command on the
CSG. In the command output, the value of PW redundancy mode is master. It indicates
that the PW redundancy mode is master/slave, and the CSG will send messages to SR1 and
SR2 to notify primary/secondary PW switchover.
2.
Run the display vpls connection command on SR1 and SR2 to check the value of
VCState. In the command output, the value of VCState is Up, which indicates that the
Layer 2 tunnel has been set up.
3.
Run the display this command in the VSI-LDP view on SR1 and SR2 to check whether
the parameter ignore-standby-state has been configured for PWs. The command output
shows that this parameter has not been configured.
On the network where PW redundancy in M/S mode is configured, if the primary PW fails,
traffic will be switched to the secondary PW. If the secondary PW is in Backup state, traffic
cannot be forwarded, which results in packet loss. If the parameter ignore-standby-state
is configured for the PW on the SR, the PW will ignore the secondary state sent from the
peer and be always in the forwarding state. This configuration can prevent packet loss
during primary/secondary PW switchover.
Procedure
Step 2 Run the vsi vsi-name command to enter the VSI view.
Step 3 Run the undo peer peer-address [ negotiation-vc-id vc-id ] command to delete the existing
PW.
Step 4 Run the peer peer-address [ negotiation-vc-id vc-id ] [ tnl-policy policy-name ] ignorestandby-state command to create a new VPLS PW and configure it to ignore the secondary
state sent from the peer.
After the operations, the number of lost packets decreases dramatically. The fault is rectified.
----End
Summary
On the IPRAN with the networking of HVPLS + L3VPN, the parameter ignore-standbystate needs to be configured in the peer command when a VPLS peer is configured. This
parameter configures a PW to ignore the secondary state sent from the peer and be always in the
forwarding state. This configuration can decrease the packets lost during PW state
synchronization in the case of primary/secondary PW switchover.
5.5.2 Traffic Is Interrupted After Primary/Secondary PW

Switchover on a BTB IP RAN - PWE3 + (VSI + IP)
On a BTB IP RAN with the networking of PWE3+(VSI+IP), if the downlink AC interface
tracked by VRRP is not switched to a Layer 2 interface, the attached VPLS services will be
interrupted.
Issue 02 (2011-09-10)

135

Fault Symptom
As shown in Figure 5-6, the Layer 2 and Layer 3 networks are back-to-back. On the L2VPN,
HVPLS is deployed, and a primary PW and a secondary PW are configured for PW redundancy
in master/slave mode. A Spoke PW is configured between UPE1 and UPE2 to prevent the
network on one side of the UPEs from being affected by faults on the other side. When primary/
secondary PW switchover occurs on the network, traffic is interrupted.
Figure 5-6 Networking diagram for a BTB IP RAN - PWE3 + (VSI + IP)
UPE1
PEAGG1
CSG
PW
ary
m
i
pr
spoke
PW
NodeB
sec
ond
ary
RNC
PW
PEAGG2
HVPLS
PWE3 accessing VPLS
UPE2
IP
Fault Analysis
1.
Run the display vsi [ name vsi-name ] [ verbose ] command on UPE1 and UPE2. The
command output shows that there is a PW whose PW Type information is displayed as
MEHVPLS. It indicates that a Spoke PW has been configured.
2.
Run the display this command on the AC interface on UPE1 and UPE2. The command
output shows that the portswitch command has not been configured on the interface. VRRP
tracks the protocol status on the interface. Because the interface is bound to a VSI, the
protocol remains Down, and the VRRP backup group status on the interface cannot be
successfully negotiated.
Procedure
Step 2 Run the interface interface-type interface-number command to enter the view of a specified
interface on UPE1 or UPE2.
Step 3 Run the portswitch command to switch the interface to a Layer 2 interface.
After the operations, traffic forwarding recovers. The fault is rectified.
----End
Issue 02 (2011-09-10)

136

Summary
VRRP tracks the protocol status on an interface. To ensure that the protocol status on the interface
without an IP address is Up, you need to run the portswitch command on the interface to switch
it to a Layer 2 interface.
Issue 02 (2011-09-10)

137

Troubleshooting HUAWEI VPN

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Troubleshooting HUAWEI VPN

Загружено:

Авторское право:

Доступные форматы

HUAWEI NetEngine80E/40E Router

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

About This Document

About This Document

System maintenance engineers

Network monitoring engineers

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

About This Document

Indicates a hazard with a high level of risk, which if not

Indicates a tip that may help you solve a problem or save

Provides additional information to emphasize or supplement

The keywords of a command line are in boldface.

Command arguments are in italics.

Items (keywords or arguments) in brackets [ ] are optional.

Optional items are grouped in braces and separated by

Optional items are grouped in brackets and separated by

Optional items are grouped in braces and separated by

Optional items are grouped in brackets and separated by

The parameter before the & sign can be repeated 1 to n times.

A line starting with the # sign is comments.

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

About This Document

Changes in Issue 02 (2011-09-10)

Changes in Issue 01 (2011-05-30)

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

5 L2VPN IP RAN Troubleshooting...........................................................................................121

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

About This Chapter

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

1.1 BGP Private Network Traffic Is Interrupted

Routes are inactive because their next hops are unreachable.

Routes are inactive because they fail to be iterated to a tunnel.

1.1.2 Troubleshooting Flowchart

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router

Is the next hop of the

Ensure that the next

Is the routing policy is

Correctly configure the

Reduce the number of

Is the tunnel iterated

Ensure that the tunnel

Does the export RT

Reduce the number of

1.1.3 Troubleshooting Procedure

Huawei Proprietary and Confidential

HUAWEI NetEngine80E/40E Router