Sie sind auf Seite 1von 44

HUAWEI NetEngine5000E Core Router

V800R002C01

Troubleshooting - VPN
Issue

01

Date

2011-10-15

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 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

About This Document

About This Document


Intended Audience
This document describes the troubleshooting workflow and methods for HUAWEI
NetEngine5000E. This document describes the troubleshooting of HUAWEI
NetEngine5000E with various services, including information collection methods, common
processing flows, common troubleshooting methods, and troubleshooting cases.
This document is intended for:
l

System maintenance engineers

Commissioning engineers

Network monitoring engineers

Related Versions (Optional)


The following table lists the product versions related to this document.
Product Name

Version

HUAWEI NetEngine5000E
Core Router

V800R002C01

Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol

Description
Alerts you to a high risk hazard that could, if not avoided,
result in serious injury or death.
Alerts you to a medium or low risk hazard that could, if
not avoided, result in moderate or minor injury.

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

ii

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

Symbol

About This Document

Description
Alerts you to a potentially hazardous situation that could,
if not avoided, result in equipment damage, data loss,
performance deterioration, or unanticipated results.
Provides a tip that may help you solve a problem or save
time.
Provides additional information to emphasize or
supplement important points in the main text.

Command Conventions (Optional)


The command conventions that may be found in this document are defined as follows.
Convention

Description

Boldface

The keywords of a command line are in boldface.

Italic

Command arguments are in italics.

[]

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

{ x | y | ... }

Optional items are grouped in braces and separated by


vertical bars. One item is selected.

[ x | y | ... ]

Optional items are grouped in brackets and separated by


vertical bars. One item is selected or no item is selected.

{ x | y | ... }*

Optional items are grouped in braces and separated by


vertical bars. A minimum of one item or a maximum of all
items can be selected.

[ x | y | ... ]*

Optional items are grouped in brackets and separated by


vertical bars. Several items or no item can be selected.

&<1-n>

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

A line starting with the # sign is comments.

Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.

Changes in Issue 01 (2011-10-15)


The initial commercial release.
Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

iii

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

Contents

Contents
About This Document.....................................................................................................................ii
1 L3VPN Troubleshooting..............................................................................................................1
1.1 L3VPN Traffic Is Interrupted.............................................................................................................................2
1.1.1 Common Causes........................................................................................................................................2
1.1.2 Troubleshooting Flowchart........................................................................................................................2
1.1.3 Troubleshooting Procedure........................................................................................................................4
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......................................................8
1.2.2 Ping Between the PEs on a VPN Fails....................................................................................................11
1.2.3 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..............................................................................12
1.2.4 PEs Cannot Learn Routes After the policy vpn-target Command Is Configured on an RR...................14
1.2.5 VPN Routing Table on the PE Does Not Contain Any Route Sent from the Peer PE............................16
1.2.6 CEs Cannot Ping Through Each Other....................................................................................................18
1.2.7 Failed to transmit Large Packets of the Private Network........................................................................19
1.2.8 PE Fails to Ping Through the Remote CE Network Segment.................................................................20
1.2.9 Private Route Flapping Occurs Frequently When a Physical Interface Alternates Between Up and Down
..........................................................................................................................................................................21
1.2.10 CE Cannot Access Some Web Servers Due to the MTU Configuration...............................................27
1.2.11 The RR Fails to Reflect VPN Routes....................................................................................................29
1.2.12 CE1 Cannot Register with CE2 Because the Number of Routes of the VPN Instance Exceeds the
Maximum Limit................................................................................................................................................30
1.2.13 VPNv4 Routes on a PE Cannot Take Effect.........................................................................................32
1.2.14 MPLS VPN Convergence Is Slow.........................................................................................................35
1.2.15 One-way Audio Occurs Between the CEs Because the vpn-target import-extcommunity Command
Is Not Configured.............................................................................................................................................36
1.2.16 PEs Fail to Exchange Private Network Routes Because the Mask Set for the Loopback Interface Is Not
a 32-bit Mask....................................................................................................................................................37

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

iv

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

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 L3VPN Traffic Is Interrupted
This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting
procedure for the fault that BGP private network traffic is interrupted.
1.2 Related Troubleshooting Cases

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

1.1 L3VPN Traffic Is Interrupted


This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting
procedure for the fault that BGP private network traffic is interrupted.

1.1.1 Common Causes


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 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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

Is fault
rectified?

Yes

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

Is fault
rectified?

Yes

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

No

No

Seek technical support

Issue 01 (2011-10-15)

Is fault
rectified?

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

End

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

1.1.3 Troubleshooting Procedure


NOTE

After commands are configured to troubleshoot faults, pay attention to the configuration validation mode
to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the
immediate validation mode.
l In immediate validation mode, configurations take effect after commands are input and the Enter key
is pressed.
l In two-phase validation mode, after commands are configured, the commit command needs to be run
to commit the configurations.
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.

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 valid and best. 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 valid and best 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 ipv4-address { mask | mask-length }
command on the remote PE to check whether it has received the target route.
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.

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

If the remote PE has not received the target route, perform Step 2 to check the inbound
policy of the remote PE.
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
#
ipv6-family unicast
undo synchronization
#
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 as-number 300
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 NetEngine5000E 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 Name 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
BGP local router ID : 2.2.2.2
Local AS number : 100

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

Total routes of Route Distinguisher(1:2): 1


BGP routing table entry information of 50.1.1.2/32:
Label information (Received/Applied): 13316/NULL
From: 1.1.1.1 (1.1.1.1)
Route Duration: 00h00m08s
Relay IP Nexthop: 20.1.1.1
Relay IP Out-Interface: Pos1/0/0
Relay Tunnel Name: ldp
Original nexthop: 1.1.1.1
Qos information : 0x0
Ext-Community:RT <1 : 1>
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal,
best, select, pre 255
Not advertised to any peer yet
Total routes of vpn-instance vpna: 1
BGP routing table entry information of 50.1.1.2/32:
Label information (Received/Applied): 13316/NULL
From: 1.1.1.1 (1.1.1.1)
Route Duration: 00h00m07s
Relay Tunnel Name: ldp
Original nexthop: 1.1.1.1
Qos information : 0x0
Ext-Community:RT <1 : 1>
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 fails to be iterated to a tunnel, check whether the associated tunnel exists
or whether the tunnel configurations are correct. For details, see the HUAWEI
NetEngine5000E Troubleshooting - MPLS.

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
ip vpn-instance vpnb
route-distinguisher 1:2
vpn-target 1:1 export-extcommunity
vpn-target 1:1 import-extcommunity
#
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.
Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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
BGP local router ID : 10.1.1.2
Local AS number : 100
Total routes of Route Distinguisher(1:1): 1
BGP routing table entry information of 100.1.1.0/24:
Imported route.
Label information (Received/Applied): NULL/13312
From: 0.0.0.0 (0.0.0.0)
Route Duration: 00h21m24s
Direct Out-interface: NULL0
Original nexthop: 0.0.0.0
Qos information : 0x0
Ext-Community:RT <1 : 1>
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
BGP routing table entry information of 100.1.1.0/24:
Imported route.
From: 0.0.0.0 (0.0.0.0)
Route Duration: 00h21m24s
Direct Out-interface: NULL0
Original nexthop: 0.0.0.0
Qos information : 0x0
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select, pre
60
Not advertised to any peer yet

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.
Run the display current-configuration configuration bgp | include peer destinationaddress 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.
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 as-number 100
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 as-number 100
peer 1.1.1.1 group IBGP

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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 alarm BGPCOMM_0x08790002 hwBgpPeerRouteNumberExceed 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
BGPCOMM_0x08790001 hwBgpPeerRouteNumberThresholdExceed

Relevant Logs
None

1.2 Related Troubleshooting Cases


1.2.1 VPNs Configured with the Same VPN Target Cannot
Communicate
On a BGP/MPLS VPN network, VPNs can communicate after being configured with the same
VPN target. If two VPNs configured with the same VPN target are bound to the same IP address,
as described in this case, the two VPNs cannot communicate.

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

NOTE

After commands are configured to troubleshoot faults, pay attention to the configuration validation mode
to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the
immediate validation mode.
l In immediate validation mode, configurations take effect after commands are input and the Enter key
is pressed.
l In two-phase validation mode, after commands are configured, the commit command needs to be run
to commit the configurations.
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.

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
PE1
Loopback1
1.1.1.9/32
GE2/0/0

CE3

POS2/0/0
PE2
172.2.1.1/24

POS1/0/0
172.1.1.2/24

POS3/0/0
172.1.1.1/24

GE1/0/0

POS3/0/0
172.2.1.2/24

Loopback1
3.3.3.9/32

MPLS backbone
AS: 100
GE1/0/0
CE2
VPN-B
AS: 65420

Fault Analysis
1.

Issue 01 (2011-10-15)

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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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.

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
Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

10

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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.

1.2.2 Ping Between the PEs on a VPN Fails


NOTE

After commands are configured to troubleshoot faults, pay attention to the configuration validation mode
to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the
immediate validation mode.
l In immediate validation mode, configurations take effect after commands are input and the Enter key
is pressed.
l In two-phase validation mode, after commands are configured, the commit command needs to be run
to commit the configurations.
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.

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 peer relationships, 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 P1 to check BGP peer relationships. You can find
that P1 establishes IBGP peer relationships with 1.1.1.1 and 1.1.1.2, as indicated by
Established in the command output.

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

11

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

4.

Run the display bgp vpnv4 all peer command on PE1 or PE2 to check VPNv4 peer
relationships. You can find that P1 establishes VPNv4 peer relationships with 1.1.1.1 and
1.1.1.2, 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.

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.
Step 3 Run the ip address ip-address { mask | mask-length } command to assign an IP address to the
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 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
NOTE

After commands are configured to troubleshoot faults, pay attention to the configuration validation mode
to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the
immediate validation mode.
l In immediate validation mode, configurations take effect after commands are input and the Enter key
is pressed.
l In two-phase validation mode, after commands are configured, the commit command needs to be run
to commit the configurations.
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 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

12

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

Fault Symptom
As shown in Figure 1-4. 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-4 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.

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.

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.

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

13

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

Procedure
Step 1 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.
Step 3 Run the ip address ip-address { mask | mask-length } command to assign an IP address to the
loopback interface.
NOTE

Change the mask length of the loopback address to 32 bits.

Step 4 Run the return command to return to the user view.


Step 5 Run the reset mpls ldp command to reset MPLS LDP.
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.4 PEs Cannot Learn Routes After the policy vpn-target


Command Is Configured on an RR
NOTE

After commands are configured to troubleshoot faults, pay attention to the configuration validation mode
to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the
immediate validation mode.
l In immediate validation mode, configurations take effect after commands are input and the Enter key
is pressed.
l In two-phase validation mode, after commands are configured, the commit command needs to be run
to commit the configurations.
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.

Fault Symptom
As shown in Figure 1-5, 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 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

14

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

Figure 1-5 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

Issue 01 (2011-10-15)

1.

Run the system-view command to enter the system view.

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.

5.

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.

Solution 2: Configure the VPN instance vpna on the RR.


1.

Run the system-view command to enter the system view.

2.

Run the ip vpn-instance vpn-instance-name command to create the VPN instance


vpna.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.

15

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

3.

1 L3VPN Troubleshooting

Run the vpn-target vpn-target command to associate the VPN target with vpna.
NOTE

Note: vpn-target must be the same as that of vpna configured on the PEs.

4.

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.5 VPN Routing Table on the PE Does Not Contain Any Route
Sent from the Peer PE
NOTE

After commands are configured to troubleshoot faults, pay attention to the configuration validation mode
to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the
immediate validation mode.
l In immediate validation mode, configurations take effect after commands are input and the Enter key
is pressed.
l In two-phase validation mode, after commands are configured, the commit command needs to be run
to commit the configurations.
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.

Fault Symptom
Figure 1-6 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-6 is as follows:


l
Issue 01 (2011-10-15)

EBGP runs on the PEs and the CEs.


Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.

16

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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.

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 vpn-instance vpn-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
BGP local router ID : 3.3.3.3
Local AS number : 100
Paths:
1 available, 0 best, 0 select
BGP routing table entry information of 66::66/128
Label information (Received/Applied): 105472/NULL
From: 1.1.1.1 (1.1.1.1)
Route Duration: 00h02m17s
Relay Tunnel Out-Interface:
Relay token: 0x0
Original nexthop: ::FFFF:1.1.1.1
Qos information : 0x0
Ext-Community:RT <1 : 1>
AS-path 65420, origin igp, MED 0, localpref 100, pref-val 0, internal, pre
255
Not advertised to any peer yet

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.

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

17

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

Procedure
Step 1 Run the interface gigabitethernet 1/0/0 command on PE2 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.
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.6 CEs Cannot Ping Through Each Other


NOTE

After commands are configured to troubleshoot faults, pay attention to the configuration validation mode
to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the
immediate validation mode.
l In immediate validation mode, configurations take effect after commands are input and the Enter key
is pressed.
l In two-phase validation mode, after commands are configured, the commit command needs to be run
to commit the configurations.
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.

Fault Symptom
BGP/MPLS IPv6 VPN services are configured in the network shown in Figure 1-7. CE1 and
CE2 belong to the same IPv6 VPN. After the configuration, CE1 cannot ping through CE2.
Figure 1-7 Networking diagram of BGP/MPLS IPv6 VPN

Loopback 1

Loopback 1

PE1

PE2
P1

CE1

Issue 01 (2011-10-15)

P2

CE2

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

18

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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.
Step 3 Run the quit command to return to the system view.
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.
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.7 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.
Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

19

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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.

1.2.8 PE Fails to Ping Through the Remote CE Network Segment


Fault Symptom
Figure 1-8 Networking diagram of BGP/MPLS IPv6 VPN

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
Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

20

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

As shown in Figure 1-8, 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 vpn-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 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 vpn-instance vpninstance-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.
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 vpn-instance vpn-instance-name dest-ip-address command with the ping ipv6 -a
source-ipv6-address vpn-instance vpn-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.9 Private Route Flapping Occurs Frequently When a Physical


Interface Alternates Between Up and Down
NOTE

After commands are configured to troubleshoot faults, pay attention to the configuration validation mode
to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the
immediate validation mode.
l In immediate validation mode, configurations take effect after commands are input and the Enter key
is pressed.
l In two-phase validation mode, after commands are configured, the commit command needs to be run
to commit the configurations.
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 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

21

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

Fault Symptom
On the network shown in Figure 1-9, 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.
Figure 1-9 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 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 for forwarding
-----------------------------------------------------------------------------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.
Database information for ISIS(100)
---------------------------------Level-2 Link State Database
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

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

22

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting
Database information for ISIS(100)
---------------------------------Level-2 Link State Database
Seq Num
Checksum
Holdtime

LSPID
Length ATT/P/
OL
-----------------------------------------------------------------------------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 01 (2011-10-15)

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
GigabitEthernet3/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

:
:

3
12

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

23

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

IngressLsrID
: 1.1.1.2
LocalLspID
: 32773
Tunnel-Interface
: Tunnel1/0/2
Fec
: 1.1.1.1/32
Nexthop
: 1.1.2.2
In-Label
: NULL
Out-Label
: 65581
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

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

24

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

......
-----------------------------------------------------------------------------TOTAL: 36 session(s) Found.
LAM : Label Advertisement Mode
SsnAge Unit : DDD:HH:MM

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
GigabitEthernet1/0/0
-----------------------------------------------------------------------------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:
Unicast: 400093379625 packets, Multicast: 973669 packets
Broadcast: 755 packets, JumboOctets: 1138327781 packets
System: 0 packets, Overruns: 0 packets
TxPause: 0 packets
Unknown Vlan: 0 packets
GigabitEthernet1/0/0 current state : UP
Line protocol current state : DOWN

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

25

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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: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:
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:
Unicast: 400093379625 packets, Multicast: 973669 packets
Broadcast: 755 packets, JumboOctets: 1138327781 packets
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, packets are not directly sent from Router A to Router B. Instead,
packets from Router A pass through Router C to reach Router B. The fault is rectified and services
become normal.
----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.

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

26

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

1.2.10 CE Cannot Access Some Web Servers Due to the MTU


Configuration
Fault Symptom
On the network shown in Figure 1-10, 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.
Figure 1-10 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 lsp verbose 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

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

27

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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.
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 commit command to commit the configuration.


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.
Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

28

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

1.2.11 The RR Fails to Reflect VPN Routes


Fault Symptom
On the network shown in Figure 1-11, 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.
Figure 1-11 Networking diagram of the RR failing to reflect VPN routes

Route Reflector

PE1
(Client1)

CE1

PE2
(Client2)

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

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

29

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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.
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.12 CE1 Cannot Register with CE2 Because the Number of Routes
of the VPN Instance Exceeds the Maximum Limit
Fault Symptom
On the network shown in Figure 1-12, 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 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

30

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

Figure 1-12 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.
Total routes of Route Distinguisher(65029:2995): 2
BGP routing table entry information of 10.1.1.1/24:
Label information (Received/Applied): 589826/NULL
From: 11.1.1.1 (11.1.1.1)
Original nexthop: 12.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
Not advertised to any peer yet
BGP routing table entry information of 172.16.7.20/30:
Label information (Received/Applied): 589826/NULL
From: 11.1.1.2 (11.1.1.2)
Original nexthop: 12.1.1.1
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
Not advertised to any peer yet

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

31

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

5.

1 L3VPN Troubleshooting

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
route-distinguisher 65029:2995
apply-label per-instance
routing-table limit 100 80
vpn-target 65029:2995 export-extcommunity
vpn-target 65029:2995 import-extcommunity

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 prefix 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.13 VPNv4 Routes on a PE Cannot Take Effect


Fault Symptom
On the network shown in Figure 1-13, 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.

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

32

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

Figure 1-13 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

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

Issue 01 (2011-10-15)

BGP

Process ID:

255

Cost:

10.1.1.1

Interface:

0.0.0.0

Neighbour:

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

33

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN
Label: 109568

1 L3VPN Troubleshooting
Tunnel ID:

0x0
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 1 Run the system-view command on PE1 to enter the system view.
Step 2 Run the mpls command to enable MPLS and enter the MPLS view.
Step 3 Run the quit command to return to the system view.
Step 4 Run the mpls ldp command to enable LDP globally and enter the MPLS LDP view.
Step 5 (Optional) Run the lsr-id lsr-id command to set the LSR ID for the LDP instance.
Step 6 Run the quit command to return to the system view.
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.
Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

34

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

1.2.14 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-14 Typical Network Diagram for MPLS VPN

PE1

PE3

PE2

PE4 PE5

CE1

PE6

CE2

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 1 Run the system-view command on PE3 to enter the system view.
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.
Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

35

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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.15 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-15, 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.
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-15 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 4

PE 3
Network

Phone1
Issue 01 (2011-10-15)

Phone2
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.

36

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

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.
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.16 PEs Fail to Exchange Private Network Routes Because the


Mask Set for the Loopback Interface Is Not a 32-bit Mask

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

37

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

NOTE

After commands are configured to troubleshoot faults, pay attention to the configuration validation mode
to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the
immediate validation mode.
l In immediate validation mode, configurations take effect after commands are input and the Enter key
is pressed.
l In two-phase validation mode, after commands are configured, the commit command needs to be run
to commit the configurations.
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.

Fault Symptom
On the network shown in Figure 1-16, 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-16 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.

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.

2.

Run the display mpls ldp session command on the P. The command output shows that the
LDP peer relationship between the P and PE is in the Operational state, meaning that the
LDP peer relationship has been 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.

Issue 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

38

HUAWEI NetEngine5000E Core Router


Troubleshooting - VPN

1 L3VPN Troubleshooting

Take the display on PE1 as an example.


Destination/Mask
1.1.1.0/24

6.

Proto Pre
Direct 0

Cost
0

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.
Take the display on PE1 as an example.
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 1 Run the system-view command on PE1 and PE2 to enter the system view.
Step 2 Run the interface loopback1 command on PE1 and PE2 to enter the view of Loopback1 bound
to the VPN instance.
Step 3 Run the ip address ip-address { mask | mask-length } command on PE1 and PE2 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 01 (2011-10-15)

Huawei Proprietary and Confidential


Copyright Huawei Technologies Co., Ltd.

39