Troubleshooting - VPN (V800R002C01 - 01)

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.

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)

ii

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)

iii

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)

iv

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)


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)


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?

End

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)


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


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

Label information (Received/Applied): 13316/NULL
From: 1.1.1.1 (1.1.1.1)
Relay IP Nexthop: 20.1.1.1
Relay IP Out-Interface: Pos1/0/0
Relay Tunnel Name: ldp
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 Name: ldp
best, select, active, pre 255
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
#
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)


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


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)


NOTE
is pressed.
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.

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)

10

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
is pressed.
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)

11

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

12

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)

13

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.
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
is pressed.
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)

14

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

3.
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
is pressed.
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.

16

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
Paths:
1 available, 0 best, 0 select
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.
Issue 01 (2011-10-15)

17

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
is pressed.
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.
Loopback 1
Loopback 1
PE1
PE2
P1
CE1
Issue 01 (2011-10-15)
P2
CE2

18

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)

19

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
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)

20

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

21

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.
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)

22

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

23

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)

24

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

25

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:
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, 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)

26

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)

27

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)

28

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)

29

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)

30

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

31

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 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)

32

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:

33

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

34

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 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)

35

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
36

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)

37

NOTE
is pressed.
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)

38

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)

39

Troubleshooting - VPN (V800R002C01 - 01)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Troubleshooting - VPN (V800R002C01 - 01)

Uploaded by

Copyright:

Available Formats

HUAWEI NetEngine5000E Core 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 NetEngine5000E Core Router

About This Document

About This Document

System maintenance engineers

Network monitoring engineers

Related Versions (Optional)

Huawei Proprietary and Confidential

HUAWEI NetEngine5000E Core Router

About This Document

Command Conventions (Optional)

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.

Changes in Issue 01 (2011-10-15)

Huawei Proprietary and Confidential

HUAWEI NetEngine5000E Core Router

Huawei Proprietary and Confidential

HUAWEI NetEngine5000E Core Router

About This Chapter

Huawei Proprietary and Confidential

HUAWEI NetEngine5000E Core Router

1.1 L3VPN Traffic Is Interrupted

1.1.1 Common Causes

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 NetEngine5000E Core Router

Ensure that the next

Correctly configure the

Reduce the number of

Ensure that the tunnel

Reduce the number of

Seek technical support

Huawei Proprietary and Confidential

HUAWEI NetEngine5000E Core Router

1.1.3 Troubleshooting Procedure

Huawei Proprietary and Confidential

HUAWEI NetEngine5000E Core Router

Step 3 Check that routes can be iterated to a tunnel.

Huawei Proprietary and Confidential

HUAWEI NetEngine5000E Core Router

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

If the target route can be iterated to a tunnel, go to Step 4.

Huawei Proprietary and Confidential

HUAWEI NetEngine5000E Core Router

Huawei Proprietary and Confidential

HUAWEI NetEngine5000E Core Router

peer 1.1.1.1 enable

If the alarm BGPCOMM_0x08790002 hwBgpPeerRouteNumberExceed is generated when